[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Best Practices enquiry
From: |
david |
Subject: |
Re: Best Practices enquiry |
Date: |
Thu, 5 Feb 2004 11:07:39 -0600 (CST) |
>
> On the flip side, and maybe this is what Jim really meant, you can tag
> your committed versions on the contributor branch when the bug fix is
> done (and after the merge is complete). Then remember that tag for the
> next bug fix. You can use that tag as the common ancestor for the next
> merge. The bad part of this is that you must religiously tag the contributor
> branch after every merge (which is counter-intuitive), and you must remember
> the tag (perhaps for a long period of time) until the next bug fix. Note
> also that this procedure must be bootstrapped by applying the first bug fix
> tag at the time the branch is created. All told, this is a fine method that
> also fits neatly into the "best practice" category.
>
If you can get your developers to use a script to merge (which they'll
likely want to do when they see the manual way), and have a consistent
tag naming convention, you can automate the merging process. I did that
once, and it worked very well. The developers were happy, and I was
happy not to have to deal with user merge problems.