The repository encapsulates everything in src_root_dir/ and then you can change any file or files within the folder in any given branch and then merge them together as you see fit. However, this is true with all version control systems that have branches (all of them I guess?). In git-land, the easier solution when working alone or even in small groups, is just to use stashes ( http://gitready.com/beginner/2009/01/10/stashing-your-changes.html) which are just simple ways of putting uncommitted changes on hold while working other aspects of the project (i.e. put the feature on hold and do a quick hotfix). I think it's bad form to work on more than one feature at a time and since branches are mostly only useful when more than one feature is being worked on, you can just not worry about branches until later on. Even on a recent project with 10 developers, we tried not to publish branches and that worked very well in terms of having fewer merge conflicts. An important part of that style is to reduce the size of features to be so small that they can be done in a day or two. With that said, I know many fine developers who use branches all the time even on solo projects. https://twitter.com/varud https://www.linkedin.com/in/adamcnelson On Mon, Mar 18, 2013 at 3:13 PM, James Nzomo <kazikubwa@gmail.com> wrote:
Thanks fellas for all those valuable pointers. Just 1 last n00b question...please bear with me. It might be abit layman
Suppose my source tree is like so:-
*+/src_root_dir* * |* * +/dir_with_common_src_a/* * |* * +/dir_with_common_src_b/* * |* * +/dir_with_src_serv_conflicting_requirements/* * |* * .common.cpp* * |* * .common.h* * |* * .projec_file_(need_2_of_these_coz_of_the_above_red_headache).cbp*
Can they all gimme different branches with only the red being different*(including the solo project file) * & the green being the same across all branches..even after mods.
Yaani... i'd like the red to vary but the green to remain common.
_______________________________________________
*In programming, as in everything else, to be in error is to be reborn.** * _______________________________________________ *
*
2013/3/18 Adam Nelson <adam@varud.com>
I'll be the most opinionated here:
Use git and ideally use Github.
Hg (mercurial) is a fine alternative but it doesn't have the penetration git has (i.e. Microsoft supports git natively in Visual Studio).
Using SVN is selling yourself short. There are tens of thousands of projects using SVN but many new projects are started on a DVCS like git. Git is where most new innovative projects are happening, and to a degree Mercurial, but I can't think of anybody I know starting a project on SVN anymore.
-Adam
On Mon, Mar 18, 2013 at 9:44 AM, Kiti Chigiri <kiti.chigiri@gmail.com>wrote:
+1 on the pain in the neck when merging from svn.
Having worked on both svn and git in a cloud hosted enviroment(jira and bitbucket) with a huge codebase, I found git to work much better than svn.
On Mon, Mar 18, 2013 at 9:37 AM, Martin Chiteri < martin.chiteri@gmail.com> wrote:
I agree with @Rad, performance differences between git and hg are negligible since it usually boils down to slight variances on the number of machine cycles taken to do some of the operations. Also, using dvc's takes a little different frame of mind to utilize well.
One other thing I would like you to note is that you should consider if you are going to have many branching and by extension merging operations applied to your source tree. If say have lots modules or features, some experimental being worked on in parallel by different people which are re-integrated to the mainline code every few days / weeks, chances are high that git or hg are better suited for the task. Last time I checked, svn as of version 1.5, was a pain in the neck to do merge operations. It is possible albeit very confusing in my opinion. In addition you lose all the commit history logged during the branching operations.
With git and hg, this is arguably the most natural thing to do. In fact every checkout from a git or Mercurial repository is essentially a remote branch which can be pushed back later. Luckily for svn users there is a git-svn translation utility to assist in doing branch / merge to svn repos http://stackoverflow.com/questions/12605767/git-svn-merging-and-committing-b.... You can use the same tool to work entirely with subversion repositories through a git client.
Martin.
On Mon, Mar 18, 2013 at 9:07 AM, Rad! <conradakunga@gmail.com> wrote:
Having used all I echo Martin's views apart from the following - the performance difference between git and mercurial is negligible in most cases - git allows you to easily modify commits. Some folks don't think this is a good thing. (you can in mercurial too, but you need to do a bit of work) - to use a dvcs you must really understand the fundamentals of a dvcs. Don't just use the way you use SVN - there are subtle differences that can lead to you shooting yourself in the foot
On Monday, March 18, 2013, Martin Chiteri wrote:
Hi James,
A more general rule-of-thumb is to use svn when you have good access to a shared network infrastructure and for some reason (administrative maybe?) you need to have a centralized repository for sources.
Git / Mercurial works well when you at times need to work offline and the nature of your project is somewhat de-centralized (kind-of peer to peer).
I love git and *always* use it for my personal projects but I prefer svn at work. Also in the beginning git required a little more brain-power to use than svn so it may appear to be less newbie friendly than svn. Currently, they are more-or less as easy to use.
I always prefer git to Mercurial since they are both distributed VCS but git is said to be as lighting fast. This should be because git is entirely written in C, Mercurial is Python-based so it most probably suffers from the overhead of an interpreter.
Have never used bazaar so cannot comment on it. You can try them all and make your pick.
Martin.
On 3/17/13, James Nzomo <kazikubwa@gmail.com> wrote: > Hello sw-dev oriented skunks! > > I've been raking my head about a SW project for various users, each with > "slightly" different requirements. > It's a nightmare coming up with 1 solution that fits all, so i decided to > experiment with a VC system. > > What VCS (among the above) would you recommend for a proprietary sw app? > > > _______________________________________________ > > *In programming, as in everything else, to be in error is to be reborn.** * > _______________________________________________ > * > > * > _______________________________________________ skunkworks mailing list skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------
Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
_______________________________________________ skunkworks mailing list skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------
Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
_______________________________________________ skunkworks mailing list skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------
Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
_______________________________________________ skunkworks mailing list skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------
Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
_______________________________________________ skunkworks mailing list skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------
Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
_______________________________________________ skunkworks mailing list skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------
Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke