Jump to content

  • Log In with Google      Sign In   
  • Create Account


Source control - branching strategies


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 ChaosEngine   Crossbones+   -  Reputation: 2150

Like
1Likes
Like

Posted 20 December 2012 - 03:08 PM

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.
if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

Sponsor:

#2 Telastyn   Crossbones+   -  Reputation: 3724

Like
4Likes
Like

Posted 20 December 2012 - 03:21 PM

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.

#3 ApochPiQ   Moderators   -  Reputation: 14305

Like
2Likes
Like

Posted 20 December 2012 - 04:14 PM

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.

#4 ChaosEngine   Crossbones+   -  Reputation: 2150

Like
0Likes
Like

Posted 20 December 2012 - 05:10 PM

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)?
if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

#5 Telastyn   Crossbones+   -  Reputation: 3724

Like
0Likes
Like

Posted 20 December 2012 - 05:41 PM

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)

Edited by Telastyn, 20 December 2012 - 05:42 PM.


#6 KaiserJohan   Members   -  Reputation: 1039

Like
0Likes
Like

Posted 21 December 2012 - 02:56 AM

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.



#7 Acid-Chris   Members   -  Reputation: 454

Like
0Likes
Like

Posted 21 December 2012 - 03:35 AM

If you can afford it, you should take a look at Clear Case.



#8 samoth   Crossbones+   -  Reputation: 4523

Like
0Likes
Like

Posted 21 December 2012 - 06:12 AM

[...] 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?

 



#9 DareDeveloper   GDNet+   -  Reputation: 897

Like
0Likes
Like

Posted 21 December 2012 - 06:15 AM

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.


Given enough eyeballs, all mysteries are shallow.

ProcGames.com


#10 Yrjö P.   Crossbones+   -  Reputation: 1412

Like
0Likes
Like

Posted 21 December 2012 - 10:11 AM


[...] 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.



#11 BinaryPhysics   Members   -  Reputation: 294

Like
0Likes
Like

Posted 22 December 2012 - 09:10 PM

I used something similar before hand but my house mate showed me a technique he found called git-flow. It's amazingly helpful and I now use it for all my projects.

 

It's really just an idea but it's got a tool that apparently is being considered for merging into the mainline of Git.



#12 Trienco   Crossbones+   -  Reputation: 2057

Like
0Likes
Like

Posted 23 December 2012 - 07:00 AM

Well, since the idea is apparently to move away from exclusive locking, ClearCase is clearly out. Also for a million other reasons that could make me rant for hours. After a few years of CC as work, people can't wait to migrate to just about anything that isn't a user-hating excuse to sell expensive trainings. Any tool that lets you remove a view without even warning you about remaining checkouts (after which only admin intervention will allow anybody to continue working) is clearly aimed at securing the jobs of CC admins.

 

Another thing that turned out to be extremely annoying is Visual Studio integration. Accidentally type in a file -> reserved checkout "behind your back". Point is: too much (or too automated) integration isn't always a good thing.

 

We're going to move to git for now, using the same strategy as described by Telastyn. Dev branches for everyone, task branches if appropriate, releases are branched off of main and closed/locked/killed after a release. No working on main other than merging changes back to it. Though I got a feeling nobody will stick to that for small one-line fixes, especially since with git you might already consider your local repository as kind of a temporary branch (except if your machine dies, your changes are lost and you will push changes instead of actually merging).


f@dzhttp://festini.device-zero.de

#13 BinaryPhysics   Members   -  Reputation: 294

Like
0Likes
Like

Posted 23 December 2012 - 11:48 AM

Dev branches for everyone, task branches if appropriate, releases are branched off of main and closed/locked/killed after a release. No working on main other than merging changes back to it. Though I got a feeling nobody will stick to that for small one-line fixes, especially since with git you might already consider your local repository as kind of a temporary branch (except if your machine dies, your changes are lost and you will push changes instead of actually merging).

You've basically just described git-flow. Tag your branches with prefixes so people know what is expected on that branch. Make use of 'hotfix/branch-name' for fixes that need to be done then have them merged to master.

Edited by BinaryPhysics, 23 December 2012 - 11:48 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS