On Fri, Jul 03, 2009 at 01:22:29AM -0700, Oliver Mangold wrote:
> Assume the following scenario:
>
> User A moves/renames file 'foo' to 'bar'.
> User B edits file 'foo'.
>
> Both users do update then commit (it doesn't matter in which order the server sees the operations, I would like any order to work).
>
> Then (depending on svn version) the result is:
>
> - either a conflict
> - or user B sees a unedited file 'bar' which is part of the repository, and an additional unversioned file foo with his changes.
>
> Is there a chance to make subversion handle this in the way that the
> result is simply one (moved and edited) file bar?
It works today, but if and only if (quoting
http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html)
Local edits to the file bar.c, which is renamed during an update to
baz.c, will only be applied to bar.c if your working copy of bar.c is
based on the revision in which it was last modified before being moved
in the repository. Otherwise, Subversion will resort to retreiving baz.c
from the repository, and will not try to transfer your local
modifications to it. You will have to do so manually.
Making this work all the time is our long-term goal.
It's not easy because currently the concept of moves in Subversion
is not exactly advanced..
Making this work all the time is our long-term goal.
It's not easy because currently the concept of moves in Subversion
is not exactly advanced, which is also why the stupid restriction
described above currently applies. The currently implemented "solution"
to carry over local edits to bar.c is a hack on top of broken design,
not a proper solution.
But before we can fix this, we have to rewrite the working copy code,
which is work in progress and will first show up in 1.7.
> Git doesn't have a problem with this.
But Git has other problems. As does Subversion/Mercurial/YouNameIt.
Every tool has problems.
Stefan
Received on 2009-07-03 12:36:06 CEST