Re: Problem mergin moves from different repos

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

Yeah... I now see the point.
I think the b) solution would be better for consistency:

The main problem is that "move" statements are not considered as a
change. After a move in a repository you get:

<entry
   committed-rev="3"
   name="d"
   text-time="2004-10-15T11:49:58.000000Z"
   committed-date="2004-10-15T11:50:08.004646Z"
   checksum="e9da2aa3420f529c0aaf7fd5e9da7156"
   last-author="root"
   kind="file"
   schedule="delete"
   revision="3"/>
<entry
   name="e"
   copied="true"
   kind="file"
   copyfrom-rev="3"
   schedule="add"
   copyfrom-url="file:///tmp/test/svn/devel/d"/>

You get a new file 'e' copied from rev 3 of file 'd'.

If you are merging that "move" changeset in other repository with
solution a) you get a file 'e', copy from rev 3 'd' from original
repository, with all the modifications to file d merged in previous
changesets.

If you are merging a specific changeset, you should be conscious of what
you are doing, and if you only want the move, you should be allowed to
do that.

Of course I see the main problems: If you merge that 'move' then you
will not be able to apply later previous changesets to the new
repository, because those will try to find the old file name.

An ideal solution could be something like having a UID for each file, so
all changes are applied by uid, not by path. That will allow all kinds
of merges between repos, just requiring some base common revision, so
the UIDs are the same in boths. (I know, i know... this is not possible
now with subversion and will need a lot of changes, I just
brainstorming :) )

A partial solution could be showing a warning like "before merging 'move
d to e' in changeset 10 you may want to merge changesets 4, 6, 9 which
modify that file, or latter you will need to do that by hand"

-- 
 !)     bisho! -=] 15/10/2004 [=-
!  ',  _
 !   ) ·>
  ?     )  ::    Don't promote SW Monopolies. Say NO to software      :: 
,???---'   ::                         patents                         :: 
[ PEACE ]  ::            EuropeSwPatentFree Demostration:             :: 
    ......::                  http://online-demo.org                  ::
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org