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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]