I'm looking into changing source control providers at work. Currently we're using a source safe style exclusive locking system with all the problems that incurs. It hasn't been a big deal up to this point but the lack of good branching is really starting to bite us.
Does anyone have any good recommendations for modern best practice with branching strategies (i.e. branch by purpose, is trunk stable, etc)?
Would appreciate any good articles or thoughts.
Source control - branching strategies
Have Dev and Main. Dev is where developers work, Main is QA stable. Task branches (if prudent) come off of dev. Release branches come off of Main.
I've worked 4 places now, and this is the most common setup and solve most problems for the general case.
I've worked 4 places now, and this is the most common setup and solve most problems for the general case.
Agreed.
Also, your branching strategy will depend heavily on what version control provider you use. For instance, with Mercurial or a similar DVCS, you can split and merge branches so easily and automatically that it just makes sense for everyone to branch exactly what they need to modify and then merge back into main trunk. Perforce is nice if you have a lot of binary data to hold, but doesn't branch as cleanly. SVN and its ilk are probably among the worst for branch flexibility.
Also, your branching strategy will depend heavily on what version control provider you use. For instance, with Mercurial or a similar DVCS, you can split and merge branches so easily and automatically that it just makes sense for everyone to branch exactly what they need to modify and then merge back into main trunk. Perforce is nice if you have a lot of binary data to hold, but doesn't branch as cleanly. SVN and its ilk are probably among the worst for branch flexibility.
Author
Thanks guys... that's pretty much along the lines of what I'd been thinking. As for provider, that's up for decision as well.
Was leaning towards git, but also considering mercurial.
Some questions for anyone who's used them: how well do they handle merging C# projects? What about Visual Studio integration (is that even worth it)?
Was leaning towards git, but also considering mercurial.
Some questions for anyone who's used them: how well do they handle merging C# projects? What about Visual Studio integration (is that even worth it)?
I would argue that Visual Studio integration is vital, but that's perhaps my bias. I know git has a plug-in that is pretty solid, though no personal experience. TFS is still solidly king in the C# bizdev world. (though perhaps less solid than ~2 years ago)
I've used SVN and Git, and I find Git is really nice for creating and switching branches whenever I would need it (not all too often). I still prefer SVN to Git though, just less complex and less work.
[...] Mercurial or a similar DVCS, you can split and merge branches so easily and automatically
(Slightly off-topic) This is an argument I see popping up regularly when people discuss source control, and I never quite get it. Is this actually the case? I daresay no.
Branching is simple in every version control system that I've seen except RCS (which is a nightmare doing any kind of operation, not just this one). The process may be a second or two faster or slower on one or the other system, but it's a single command (or click if you have GUI integration). I couldn't imagine how it could be any simpler.
Merging on the other hand is easy and automatic in every version control system I know if there are no conflicts. If there are conflicts, merging requires human interaction, which may be easy or may cause the merger to throw his monitor out of the window.
Inhowfar does the version control system being distributed make the process of manually reviewing lines in source files (that have interdependencies in the worst case) easier?
I don't know about Visual Studio ... but if you want to take a closer look at Git make sure the integration offers a nice way to work with the index.
SmartGit is worth the cost ... but not integrated with the IDE of course.
Most of the other tools/integrations I know are confusing and if you switch from a simple solution it is pretty dangerous to learn by doing (especially with those tools). There is quite a learning curve.
Maybe it offers easier branching ... but you need to figure out workflows that work for you.
Make sure you have enough time to get used to it - if possible appoint one person as the Git specialist who really looks into the ins and outs of Git.
Where I worked many people agreed that there needs to be a certain complexity to justify choosing Git over SVN and even CVS. It doesn't just make your life easier.
[...] Mercurial or a similar DVCS, you can split and merge branches so easily and automatically
(Slightly off-topic) This is an argument I see popping up regularly when people discuss source control, and I never quite get it. Is this actually the case? I daresay no.
...Merging on the other hand is easy and automatic in every version control system I know if there are no conflicts. If there are conflicts, merging requires human interaction, which may be easy or may cause the merger to throw his monitor out of the window.
Inhowfar does the version control system being distributed make the process of manually reviewing lines in source files (that have interdependencies in the worst case) easier?
Wrong question. The difference is that a smarter VCS doing a merge can handle automatically a ton of situations in which a dumber VCS will force you to manually review stuff. In theory, "distributed" doesn't make a VCS smart at merging, but in practice the design decisions necessary for one seem to be necessary for the other.
I'm now working with some non-technical folks on a small project. There is no way I could push Git on them, and frankly Git's usability is so awful I never got fully used to it myself. So we're going with Mercurial, picking it up as we go. Looking good so far.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
