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)?
--dave
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 30 21:32:23 2007