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

Re: Issue 2897 revisited. Really.

From: Michael Sinz <Michael.Sinz_at_sinz.org>
Date: 2007-11-29 20:50:15 CET

On Nov 29, 2007 10:11 AM, Mark Phippard <markphip@gmail.com> wrote:
> On Nov 29, 2007 10:10 AM, Kamesh Jayachandran <kamesh@collab.net> wrote:
> >
> > > Ah, right, so Ph.Marek's suggestion won't work for cherry-picking. So
> > > you'll have to investigate one of the other two methods: either
> > > subtract r51 from r60 and merge the resulting patch back to trunk, or
> > > force r60 to be split into r60 and r61 when the user does the
> > > cherrypicking.
> > >
> >
> > Forcing the commit to fail if it has some local mod along with merge
> > could be easy I think, though I would prefer having something like
> > non-reflective merge editor, which I am investigating.
> I do not think anyone is suggesting you could not do the commit. Just
> that commit would somehow "magically" perform two commits instead of
> one. I honestly do not see how that is possible, but that is the
> suggestion.

Note that conflicts due to merges are not always SVN conflicts. Some
of these are where the code "diffs" just fine but an internal API
change requires the new (local) code to change its calling of that
API. This tends to be found at compile time and not directly at merge

I wonder if there is a way to not do the dual-commit method but during
the merge, figure out the differences that were actually applied as
part of the other merge. This would require incrementally applying
the merge and not bulk like we do today.

The trick is how to deal with the conflicts if they happen early in
the process but the commit to fix them are later in the process. To
me this is starting to sound more and more like the intractable
problem of merging diffs (or the inverse: diffing diffs) Yuck...

(As I go back into my hole - I don't know how much time I could put
into non-work related efforts - still far too busy to get really
involved but less busy that the prior 8 months)
> --
> Thanks
> Mark Phippard
> http://markphip.blogspot.com/
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

Michael Sinz               Technology and Engineering Director/Consultant
"Starting Startups"                          mailto:Michael.Sinz@sinz.org
My place on the web                      http://www.sinz.org/Michael.Sinz
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 29 20:50:56 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.