Hi guys,
a raft of comments here.
Jonathan S. Shapiro said:
> That is, an integration is only permitted if all outstanding trunk deltas
> have been merged into the branch.
Yep, sounds good.
> The question I originally asked was: would we allow *selective* merge. That
> is, would we permit something less than the entire state of a branch to be
> merged. Arguments for doing a selective merge from trunk to branch:
>
> 1. A complete configuration might in principle be a consistent set of
> changes. A subset of this (e.g. merging three of five changed files) almost
> certainly is not.
> 2. People want to do it anyway.
>
> This is one of those places where practicality may dictate supporting
> something that is in principle a bad idea.
>
> That said, I can't think of any compelling case for allowing selective merge
> from the branch into the trunk. The only way you can need to do this is
> because you failed to create a branch at some point when you should have
> created one. My personal opinion is that a branch should be merged into its
> parent only as a consistent whole.
Hmmm... I'm not sure I'm clear on what you mean by selective merge...
If B.3 included some changes to two entirely separate components (comp1, comp2) of one overall project Proj, and you wanted to scrap the changes you made to comp2, while still keeping the comp1 changes and merging those into the "merged" version, what do you do here?
??
Regarding conflict resolution:
I agree with jcr -- whoever checks in last has to resolve the conflicts. This also encourages frequent-checkins which is good to reduce the amount of merging required.
BTW2: one advantage of having "locking" checkouts is that it indicates to other users that someone is working on that file -- and therefore merging will be required if they change it too. (of course it's important that files can be checked out anyway somehow, if the user doesn't care ;)
Another JCR comment:
>>This would seem to require recognizing which changes have
>> already been incorporated.
>Not really, since any time you attempt to check in, if any conflicts are
>detected you get bounced into your diff tool.
I would prefer it if the checkin operation (which is of course atomic!) failed, with a message indicating which files need to have the changes integrated/merged. That way if you attempt to check in a stack of files you don't really care about the changes to, you can simply revert them en masse, and avoid stepping through a patch-like interface going "accept theirs" repeatedly.
That's a UI decision really.
(eh, BTW sorry if the "per-version" tag was not meant for public consumption, I went and mentioned it on my Advogato diary ;)
--j.
--
Justin Mason Work: http://www.netnoteinc.com/ <jm@netnoteinc.com>
Personal: http://jmason.org/ <jm@jmason.org>
"It's true that some sharks get cancer. I said this in my book."
-- William Lane, author of _Sharks Don't Get Cancer_