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

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.
  • but I don't think it will work for us. In our case there are 2 developers here, and we generally don't work on the same projects. The release dates for said projects will probably never coincide. So whatever we do will have to support independent projects.

    If all development is on the trunk, then we can only check in changes once we know they are stable & won't break the trunk. This has the benefit of letting each other know quickly if API's change. But it also can potentially hurt the other developer from making major changes since it will probably impact the other person. This style of branching was used at a previous employer where everyone worked on features for a given release.

    If we develop on branches, we get independence from stepping on each other's toes and commit often. Yes, this can potentially make merges "fun", but I think it's worth the effort in this case because of the added independence to experiment. It also just seems to fit better for us since each person is working on different releases.

    To make an analogy: The trunk is the stable portion of the tree. Everything else depends on it being solid. When we want to do something new, we create a branch, which grows upwards. Then when it's mature, we merge it back into the trunk, and the trunk gets bigger & stronger. It's not a perfect analogy, but it does pretty well IMHO.

    --
    "Perl users are the Greatful Dead fans of computer science." --slashdot comment