Patrick Dean Rusk wrote:
> I think a reasonable argument can be made that a branch shouldn't "cherry
> pick" merging changes from trunk into it. After all, it's going to have to
> work in trunk eventually, so the more that it incorporates everything in
> trunk along its own development, the more any testing reflects the final
> situation.
This isn't always true. One common scenario is that the branch
represents a version that has just been released, while new work
continues on the main trunk. In theory, the only changes taking place
on the branch are bug fixes for interim point releases, which then get
merged back into the trunk. But from time to time, a developer will
find a bug on the trunk, fix it, and then discover that it really
deserves to be merged back into the current release branch. This needs
to be done without merging the entire trunk into the current release.
There are many simple cases, but I find it difficult to conceive of a
solution that deserves to be implemented in Subversion proper but that
doesn't attack the full general solution - and I'm guessing that that's
the perspective the Subversion team has.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 6 14:20:23 2004