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.
However, if someone does cherry pick, yes, I can't see any way around doing
some very complicated revision tracking and final merging.
Patrick Rusk
"Bob Jacoby" <RJacoby@tceq.state.tx.us> wrote...
This is a good methodology when you can bring in all changes from X+1 to
HEAD. I'll have to remember that and put it in my agency's documentation.
Not sure who you were replying to, but Russ's original message that started
this thread stated he cherry picked some important fixes from the trunk and
merged them in to his branch. As Ben commented earlier, in this situation
remembering which revisions were merged and which weren't is much more
complicated.
While I think it would be beneficial to implement a partial trunk to branch
merge strategy for the simple case you outlined(and ignore the more
complicated cherry picking and other situations), it's probably not that
simple either. There's other use cases that would have to be considered that
make it more complicated such as failing if you merge in a revision outside
the block and "re-allowing" if you revert those revisions back, etc.
Of course, I'm pretty much talking out my ... since I've been playing with
subversion for all of 2 days and have now given this 2 minutes of thought.
:)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Sep 4 14:32:15 2004