Ben Collins-Sussman wrote:
> On Nov 30, 2007 4:23 PM, Blair Zajac <blair@orcaware.com> wrote:
>
>> It just works. I mean, you still can get conflicts when you merge back and you
>> resolve those just as you normally would.
>>
>> Thinking about it, I guess you might have to redo conflict resolution again when
>> you merge changes back to trunk.
>
> Yeah, I wouldn't categorize that as 'just works'. Why should a user
> have to resolve the same conflicts twice? That's an indication that
> there are some changes *not* being tracked that should be.
Normally, this hasn't been an issue in my work. In fact, I didn't even think
this was much of an issue on any svnmerge.py discussion until this discussion
came about, so the conflict resolution wasn't as painful as dealing with
determining the revisions to merge back into the branch-source. This suggests
that the conflict resolution hasn't been that painful for people.
In fact, you always have to deal with the revision range in the merge, you may
or may not get conflicts, so that's why it wasn't that large of an issue.
But now that this discussion came about, it would be nice to have it.
> Then again, if a whole set of users is already used to svnmerge.py
> doing this, and think it's acceptable, maybe it's not the end of the
> world for svn 1.5 to match the behavior. It feels like a great
> lowering of standards, though.
Standards compared to what? Perforce? ClearCase? If that has this feature,
then I can understand it being a lowering. If you haven't, then it's an
improvement.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 1 23:12:55 2007