We have have 'phase1' which is a branch off of trunk. We needed to get these features stable and out the door due to a deadline, but have 'phase2' which is a branch off of 'phase1'. 'phase1' was to be a subset of the promised functionality and we continued development. 'phase2' were required, but less critical features. We twice had to merge 'phase1' into 'phase2'. Later, 'phase1' was fixed and merged to trunk to ship to integration. Then trunk was merged back into 'phase2'. Regrettably, base classes I had deleted in 'phase2' were extended in 'phase1', thereby ensuring they were merged into trunk and then brought back into life in 'phase2'.
I thought I was getting out of here early tomorrow to head up north for the Perl-QA Hackathon. Instead, my life is now Subversion and branching hell. We're usually not in binds like this, but we're short-handed this week.
Update: Seems the problem is more subtle than I thought, but less severe. Somehow we managed to pull in a module that had been deleted a couple of months ago, but nothing actually had a dependency on it. We think what happened is that subversion didn't delete a local copy of a module which was removed and it accidentally got committed. With four developers all having touched this, it's tough to say where it happened.
darcs managed the complications of this workflow very elegantly. We actually only created one feature branch off of the trunk. They we created one ticket tracking number for each launch.
To launch phase one, a developer took a local co py of the feature branch, removed all the patches that were for the second phase, by referencing the phase2 ticket number (darcs oblit -p phase2), and then pushed the result to the trunk. Of course, there were some details and edge cases, but overall darcs handled everything rather well.
Re:a good case for darcs
Ovid on 2009-03-26T17:43:05
If (*cough*, "when") we switch, we're going to git. We're mostly happy with it. There are other issues which have cropped up which block it for now.
