RE: Best Practices enquiry
[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. -- Jim ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Best Practices enquiry
Yannick Fortin wrote: We currently have a rather standard setup. We have a branch for the stable, released version of our software where we only put bug fixes and minor improvements. All the development is made on the trunk (or short-lived branches as needed). We are a few days away from releasing a new version. After this release, we intend to switch the bulk of the work to the trunk. Wait a minute - I thought you just said the branch only contains bug fixes and minor improvements - why are you switching the bulk of the work to the trunk? Most of your work should *already* be on the trunk. Obviously, we want the bug fixes made on the stable branch to also be included in the trunk, but not the other way around. How should we proceed ? I see 3 alternatives. Either 1- Merge the branch to the trunk each time a bug fix is done on the branch, resolving (an increasing number of) conflicts as they appear (no real need for merge tags in this case); or Merge-as-you-go is the best approach. It minimizes conflicts. Remember, when you merge, you don't merge from the base of the branch to the tip, only from the previous revision to the one you just checked in. 3- Do not merge at all and manually apply the patch on both branches. This is still merging, it's just a manual merge instead of an automated merge. This is what I do if the changes are trivial. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com/) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Best Practices enquiry
--- Forwarded mail from [EMAIL PROTECTED] 1- Merge the branch to the trunk each time a bug fix is done on the branch, resolving (an increasing number of) conflicts as they appear (no real need for merge tags in this case); or Merge-as-you-go is the best approach. It minimizes conflicts. Remember, when you merge, you don't merge from the base of the branch to the tip, only from the previous revision to the one you just checked in. More specifically, from the latest version that existed before the bug fix effort commenced. Remember, there may be multiple commits, even to the same file, during the course of the change. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Best Practices enquiry
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
Re: Best Practices enquiry
Have you considered a variation on method 1? Consider this: Before beginning work on a bug fix, apply a tag to the affected files. (You can tag everything in the containing directory if it's easier). Then fix the bug. Then merge the bug fix to the trunk, using the tag as the common ancestor. The tag goes fast because its scope is small. The number of conflicts is small because they affect only those lines affected by the bug fix. 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. And the tags will proliferate, but they can be discarded at some point. --- Forwarded mail from [EMAIL PROTECTED] We currently have a rather standard setup. We have a branch for the stable, released version of our software where we only put bug fixes and minor improvements. All the development is made on the trunk (or short-lived branches as needed). We are a few days away from releasing a new version. After this release, we intend to switch the bulk of the work to the trunk. Obviously, we want the bug fixes made on the stable branch to also be included in the trunk, but not the other way around. How should we proceed ? I see 3 alternatives. Either 1- Merge the branch to the trunk each time a bug fix is done on the branch, resolving (an increasing number of) conflicts as they appear (no real need for merge tags in this case); or 2- Merge the branch to the trunk not very often, when the number of fixes is sufficiently high to warrant the 3 days that will be needed to resolve the conflicts and make sure the fixes are still relevant, and use tags to mark the merge points; or 3- Do not merge at all and manually apply the patch on both branches. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
