Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday March 26, 2009
10:08 AM

The "Joy" of Tight Deadlines

[ #38706 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'm a project now with a similar structure, and we just launched "phase 1" today.

    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

    • 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.