Re: Problem mergin moves from different repos

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
implementation.

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
     revision.

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

__________________________________________________________________________
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