[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: A modest proposal: No index or "log -g" in Subversion 1.5

From: Blair Zajac <blair_at_orcaware.com>
Date: 2007-11-30 23:23:34 CET

David Glasser wrote:
> On Nov 30, 2007 12:26 PM, Blair Zajac <blair@orcaware.com> wrote:
>> Ben Collins-Sussman wrote:
>>> On Nov 30, 2007 1:33 PM, Justin Erenkrantz <justin@erenkrantz.com> wrote:
>>>> On Nov 29, 2007 7:13 PM, David Glasser <glasser@davidglasser.net> wrote:
>>>>> On Nov 29, 2007 7:07 PM, Ben Collins-Sussman <sussman@red-bean.com> wrote:
>>>>>> I'm going to have a really hard time saying to people, "Oh hey, you
>>>>>> can now repeatedly merge trunk to your branch now without tracking
>>>>>> revisions manually. But, um, when you merge back, you better get the
>>>>>> -rX:Y argument just right." It doesn't feel like very much progress.
>>>>>> I define "success" as "the user never needs to type a revnum".
>>>>> Is svnmerge.py any better than this here? (I don't know.)
>>>>> I also do think that the -rX:Y argument can be automatically
>>>>> calculated; it just uses a different mechanism than svn:mergeinfo.
>>>> For svnmerge.py, you only need to give it the rev you want to merge -
>>>> it computes everything else. -- justin
>>> So is svnmerge.py then doing the dreaded "patch substraction" we've
>>> been discussing when it comes time to merge a feature branch back to
>>> trunk? As a way of separating the 'conflict resolution' changes out
>>> of a revision which is mostly a port of trunk changes?
>> No, it doesn't. It doesn't merge any revisions back into trunk that modified
>> the svnmerge-integrated property in the branch, it only merges original work
>> done in the branch.
> So how does that affect conflict resolution (both in the literal "svn
> resolved" sense and the higher-level "changes had to be made" sense)?

I'm not sure what exactly what information you're asking for?

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.

I guess if svnmerge did a diff between the pristine merge to the branch and what
was committed, then applied that back to the trunk, that would be a nice
addition, and presumably, would reduce merge conflicts on the trunk.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 30 23:24:13 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.