Guille -bisho- wrote:
> 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.
This would happen even in a intra-repository merge, no? I.e., there is
always the possibility that merging out of order won't work; this is
just inherent in how merging works and has nothing to do with whether
the source and target repositories are the same or not...
Going back to the hard case, there is one common case I didn't think of,
which is when applying tags. I.e., when applying a tag you could easily
end up making a copy of a file/directory that's not based on the most
recent revision (tags can be created at any time, not just "immediately").
Thinking more about it, it seems that the "copy from the most recent
revision anyway" solution is the most appropriate one.
Here's why: remember that the target repo is not a mirror of the
source repo; it is a separate repo, with its own history and local
differences, into which you simply want to on occasion apply "changes"
from the source repo.
At the point in time you merge in a change containing a copy, you
are applying the "copy" change to the target repo. But the file
you're copying in the target repo doesn't necessarily look anything
like the corresponding file in the source repo; in fact, the copy
operation may be based on a souce repo revision that hasn't even
yet been merged into the target repo. Moreover, there may be local
changes to the file that don't exist in the source repo. So in
general, there's no "right answer" to the question: what is the
correct target repo revision to base this copy on?
So I think this feature can be reasonably implemented by always
making copies from the most recent revision of the copied file in
the target repo. Anything fancier is then declared beyond the scope
of this feature.
What do other people think? How hard is this to implement?
-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 21:12:38 2004