Fog Creek Software
Discussion Board




Questions about codelines and branching

I manage the development of a rather large VB project (~300K lines of code), that has multiple developers (not all in the same location).  Currently we use VSS, but we don't ever branch the code.  I've been reading about Perforce (their "Best Practices" document), and they describe the benefits of "mainline" codelines rather than "promotion" codelines.  We don't do either one, and I'm not sure why we should?!?  What are the benefits of "branching" the  codeline, and which model (mainline vs promotion) is best?

Marcus

Marcus Blankenship
Wednesday, September 25, 2002

Well, in VSS the benefit of branching is that you can have VSS lose your source code faster than before, and corrupt your database in the blink of an eye!

If you're using VSS, don't branch - it'll just cause you tons of heartache.

Chris Tavares
Wednesday, September 25, 2002

Really?  I know that VSS isn't the greatest, and I've certainly fought my share of corruption battles, but never w/ branching.  What kind of issues have you found?

Marcus Blankenship
Wednesday, September 25, 2002

It's fashionable to complain about VSS, I've never had any problems of any sort with it apart from one time when we had a VSS 6 server and were running a VSS 5 client, that did create a few issues although the fix was trivial. Most VSS issues are due to user error in my opinion.

Tony
Wednesday, September 25, 2002

We used VSS for over 6 years and never had any serious problems. Recently our group decided to move to Perforce and I resisted, but after the first week working with it I was completely sold! It's so much better. Go for it.

Although VSS can do a real branch, there's no easy (automatic) way to integrate changes between branches. Therefore, you tend to put branching off to the very last minute before a release to avoid having to fix bugs in two (or more) places. At one point we tried using "share and pin" for our branches. That way you can fix a bug in a shared file and just re-pin it in the "branch" instead of editing the code in two places. Sounds good right? Nope. Inevitably there are incompatible changes and you wind up having to branch the file and manually sort out the diffs anyway. Further, when you create a label for a release the label gets applied to some other version after the pin. Basically, the "share and pin" approach doesn't work. So you're left with manually tracking changes between branches.

With Perforce, the best approach is to keep a "mainline" branch and each engineer works in their own private branch. As a general rule, noone should make changes directly to the mainline. You just work away in your private branch and "integrate" to the mainline when you're comfortable with your work. This way the mainline always builds (enforced by running a regular daily build). However, in your private branch you can check in whatever you want! The code can be totally broken. You can also keep entire projects in your private branch. This is all especially handy for people (like me) that use multiple computers since you can check in stuff in a half-assed state just to move it the other computer. Yeah, it turns out life isn't all roses with P4 - it's got it's quirks too. The different terminology seems weird at first, but you get used to it. Then it all makes sense, all becomes clear, and source code control isn't quite as hard anymore.

pUnk
Wednesday, September 25, 2002

<<It's fashionable to complain about VSS, I've never had any problems of any sort with it apart from one time when we had a VSS 6 server and were running a VSS 5 client, that did create a few issues although the fix was trivial. Most VSS issues are due to user error in my opinion.>>

Testing can only prove the existence of problems, never their absence.

I don't know what kind of project you had, but apart from branching, which as (as was noted) completely ineffective for real use, I've had horrible problems with check-ins appearing in history BEFORE a label even though they were placed after it (in ver 5 databases labels are completely useless in my experience, as moving a file around the VSS tree does not necessarily preserve them; ver 6 are a bit better in this respect). The totally decentralized paradigm used by VS fails badly when clocks around the network are skewed. If you consider clock skew across a network a user error, Tony, I don't want to buy any of the software you're producing.

Also, the VSS integration feature of Visual Studio 6 are also horrible - if you branch a project, there are situations in which a checkin from inside the VS environment go into one branch and others go to the others, and the user has no indication about what is happening and no control over it.

And speed is horrible - A "Get latest" on a large (few thousand files project) used to take in excess  of 20 minutes on our decently fast network.

Despite some limitations (e.g., no rename), CVS is significantly more useful for real development than VSS (robust, cross platform, internet enabled, branches that aren't perfect but work and allow reasonable re-merging) and integration it has with other systems (Tortoise integrates CVS into explorer menus, Igloo integrates it into Visual Studio, bug tracking with Bugzilla / CVSTrac / FogBUGZ / Bonsai / Tinderbox whatever) is simply superb.

Perforce and BitKeeper are probably better (never used either for more than a few minutes myself) - but CVS wins over VSS every time in my book.

Ori Berger
Thursday, September 26, 2002

My 0.02 on BitKeeper vs. CVS.

I had used CVS for a while in my (non-serious, personal) projects, and it works, but .... it's a little cumbersome. Specially, the "rename and move" pain is ... painful. I tend to change the names of things every now and then (yes, I know it's a sign of lack of organization, but ...), so I was bitten by that a few times.

Enter Bitkeeper... Renames? No problem. Moving files? No problem. The (included) GUI tools, nice to use. No need to set up a server process (I am using it on _Windows_), local repositories work without a problem....

The outcome? I have converted all my local CVS repositores to BK; now every time I am going to start a "new" proeject (IE, I create a new directory for tinkering with a new idea, app, for my CV, whatever), I set it up as a BK repository, "just in case" I decide to start versioning it :) And you know? As it's quite painless, I tend to actually use source control, which on my "CVS" days was more unlikely :)

Of course, I was a "heavy" user of Cygwin before, so having it installed was no problem ;)

Now, if only there was a nice way of being able to participate on Source Foge projects and still use BK instead of CVS... ;)

Javier Jarava
Thursday, September 26, 2002

VSS is reliable enough. Providing you run it on a dedicated machine and make sure it has stackloads of spare disk space at all times. But even then there are better products you could use.

Mr Jack
Thursday, September 26, 2002

Marcus, if you don't branch your code how do you deal with bug fixes in released versions? What happens when you need to create a 1.0.1 to address bugs while working on 2.0? This is the original motivation behind branching.
You can use branches for other things as well. For example, if you're developing several features for a new release you can have developers use a different branch for each feature. This way each feature is developed on a more stable base. Of course, you have to pay the price of integrating the new features into the mainline, but usually it's worth it. It helps if you VCS can help you with branching and merging. CVS and VSS don't do particulary well here.

igor
Thursday, September 26, 2002

Igor,

You would be surprised how many companies cannot reproduce source code for a version of software sold or sent to a client site.  Which often leads to the phrase "that version is no longer supported" -- why?  because the company/person that wrote it has no capability of making changes to what was released.

Seems like a fundamental of software engineering, right?  A universal given with respect to software practices?  Remarkably not.

Also remarkable is what some shops consider a "branch". One company's defiition:  make an image of the source control server's hard drive and install it on another server.  You now have a branch.  Better than nothing I suppose.

nowhere man
Thursday, September 26, 2002

I'll second nowhere man's experiences.  I've worked in many a place that didn't even _LABEL_ releases.

victim of the cowboy coder
Thursday, September 26, 2002


Having your old code is not enough! You should archive your build tools, too. Where I work, we sometimes need to release bugfixes for old versions, but our build tools and libraries have changed. Compiling the old code with the new build tools does not create a identical binary file. :-(

Zwarm Monkey
Thursday, September 26, 2002

There was a very nice article on configuration management and branching in the Sept. issue of IEEE Computer. Only the abstract is available online http://computer.org/computer/co2002/r9031abs.htm.
I get the dead tree version. It is well worth finding to answer your questions without a discussion of VSS vs CVS vs BitKeeper vs etc.
It explains various methods for managing the branches, when to integrate branches and suggests the best way to handle releases with branches.

Doug Withau
Thursday, September 26, 2002

Nowhere Man - I was wondering what you were up to since your tv show was cancelled.

pUnk
Thursday, September 26, 2002

We LABEL our build now, which I thought would be sufficent, but learned the hard way how wrong I was!  I have not been able to perfectly reproduce a previous build ever, which is why we are looking at branches.  We offer quarterly software updates, that contain both bug-fixes and enhancements, but (up to now) we don't do ad-hoc fixes for the product.  In an attempt to provide better customer service, with less effort, I am looking a branching.

Now the next question:  Why is Perforce (or something else) better than VSS in this area?  What specific functionality does it provide that VSS does not?

Marcus Blankenship
Thursday, September 26, 2002

At least you are labelling.  This means that you've solved 1/2 of the problem: corporate culture.  Its one thing to have a tool that can perform a task, its harder to get people to use it.

1. Perforce branches force the file to be maintained in a new directory location:

~/project/client/1.0/files...
~/project/client/1.1/files...
~/project/client/tip/files...

In this example, all the files under project/client are under source control.  I do development in the dir named "tip", and  when a branch takes place, a new dir is maintained with the branch name.

This is an advantage over PVCS and CVS in that branches require a new location.  It makes differencing branched changes against "tip" changes easier.

2. A perforce branch maintains history from the branch back to its root.  So, on the date that branche 1.1/files... was created (from tip in this example), the root (tip) is referenced in the change list history of the branch (1.1). 

3. Perforce has a merge command, which allows changes from tip to move back into 1.1, or from 1.1 into tip.  History is maintained.

4. Checkins are atomic.  You check in files as a group.  When you check in a large block of files, no one else sees the check in until its complete.  You get a unique change number for the checkin, so you can tell a bug tracking system which change number fixes a bug.

nowhere man
Friday, September 27, 2002

Thanks for the info.  I'm looking into Perforce, and checking out StarBase, too.  The best thing we have done for ourselves so far is to use FinalBuilder to automate our builds.  Thanks to everyone for your responses!

Marcus Blankenship
Friday, September 27, 2002

pUnk,

You mentioned that all you had to do is 'integrate' with the mainline - That's all well and good, but how exactly much pain is involved wth the integration process? Does it involve some poor sod manually checking all the differences between various branches? or do you trust Perforce to just automagically finger-bang everything into place...

This seems to me to be the yuckiest bit of SCM - it's easy to branch and horrible to merge. Our team tried to keep multiple features in the same codebase separate by using #defines in the code, and then manually merging them into a mainline - after a week, the devs got so fed up they abandoned them completely...

Gordon Taylor
Sunday, September 29, 2002

>> trust Perforce to just automagically finger-bang everything into place...

Actually, that brings up a whole topic of "best practices" and SCM.  The "branch and merge per change" method pUnk described is in fact the only method which ClearCase supports.  Every check out involves a branch and every check in a merge.  But, I don't think this is what the perforce "best practices" is advocating in its document http://www.perforce.com/perforce/bestpractices.html

In fact, they list 2 styles:  "mainline" and "promotion", which really do not fit into the "branch/merge per change" model - except if you consider that the mainline is really a prgression of branch/merges, which I can see.  Perforce does do a very nice job of merging changes for you - though I always get nervous sending a machine out to do a man's job.

Now that I've demonstrated how tedious the whole discussion can be, its no wonder that this is an often overlooked aspect of development.  While we discuss the finer points of SCM, our competitor is writing code, eh?

We use the "mainline" model of the perforce paper, using labels along the "trunk" to mark specific functionality enhancements and preliminary test milestones.  The policy on branch lines, for us, is that checkins can only be made against specific bugs which have made it through the bug "triage" process.

nowhere man - not really myself lately
Monday, September 30, 2002

*  Recent Topics

*  Fog Creek Home