>--- Forwarded mail from [EMAIL PROTECTED] >[EMAIL PROTECTED] 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs