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

Re: Problem mergin moves from different repos

From: Archie Cobbs <archie_at_dellroad.org>
Date: 2004-10-14 23:52:58 CEST

kfogel@collab.net wrote:
> > (Being ignorant of the details) it seems like this would be easy to support.
> > Just use the equivalent of "relative URLs" when specifying what to change.
> > Is there really more to it than that?
> Yes :-).
> Can you try describing the behavior you envision in excruciating detail?

OK, after thinkging about it I'm starting to understand the issues better.
Tell me if this sounds reasonable.. this is a proposal for semantics, not

First, there are some easy cases we can dispense with..

File modifications are "obvious" -- they function just like running patch(1).

Removing files is "easy": you just remove the file.

Adding a new file without history is "easy": you just add the file.

Now Consider adding foo/copy as a copy of foo/original, possibly with
some differences. Two cases:

 (a) foo/copy is a copy of the most recent revision of foo/original
     in the source repository.

 (b) foo/copy is a copy of some older revision of foo/original. In this
     case, foo/original may not even exist anymore in the most recent

Case (a) also seems "easy": you just copy the most recent revision of
foo/original in the target repository, and apply any differences.

Case (b) is hard: what revision of foo/original in the target repo
do we make foo/copy a copy of?

I don't know the ultimate answer here short of a full-blown
multi-repository merge tracking system. However, there are some
potentially useful partial solutions:

  1. Ignore adds-with-history: treat all adds as entirely new files
  2. Always use the most recent revision of foo/original for the
     "base" of the copy (even if that revision is old), ignoring
     the source repo revision of foo/original.
  3. Fail with an error in case (b) and/or mark the file conflicted.

I think either of solutions #2 and #3 is reasonable and would provide
useful new functionality. Probably in practice 95% of copies are
from the newest revision, so case (b) should be uncommon, in which case
solutions #2 and #3 would do the "right thing" most of the time...
Maybe there could be a new flag to specify behavior #2 or #3.


Archie Cobbs * CTO, Awarix * http://www.awarix.com

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 15 00:00:20 2004

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.