info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Best Practices enquiry


From: Paul Sander
Subject: RE: Best Practices enquiry
Date: Thu, 5 Feb 2004 06:00:11 -0800

>--- Forwarded mail from address@hidden

>address@hidden wrote:
>> The bad part is that you need to know in advance what you're going to
>> change in persuit of the bug fix, so that it can be tagged.
>No, you don't. You just go ahead and make your changes for the bug fix. When
>you're ready to check in, *then* you tag the files you've changed. Simple.

Remember, we're talking "best practice" here, not "simple practice".  The
idea is to make the merges efficient by keeping the common ancestor of a
3-way merge as close to the changes as possible.  The best way to do that
is to apply a version tag before starting work.  That tag is given to "cvs
update" as the common ancestor when the merge is done.  The contributing
version is also identified by its branch on the "cvs update" command line.

Yes, Jim's method will work.  But you'll find that after many merges from
long-lived branches you'll have to re-resolve old merge conflicts.

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.

>--- End of forwarded message from address@hidden





reply via email to

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