[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
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
--- 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
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.
Hi all.
I would like to have the opinion of the experts here regarding when
to merge.
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
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.
