Gary Feldman wrote:
> 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.
True, in this case cherry picking from the trunk is required, but I
would think that part is generally not difficult in subversion due to
the repository-wide revision numbers. In this use case, the branch does
not generally need to be merged back into the trunk, as long as the
developers follow a policy of doing new work on the trunk and then
merging back to the release branches selectively. Therefore, the
complicated use case of the branch containing cherry-picked changes
needing to be merged back into the trunk is moot.
> 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.
As per Greg Hudson's "A response to Tom Lord's 'Diagnosing svn'" article
(google for it), changeset oriented change control is hard and generally
unnecessary most of the time -- therefore IMHO it would make sense to
implement the 95% solution and support simple repeated merging, rather
than trying to implement the general solution.
Cheers,
Raman
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 6 17:56:15 2004