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