Local modifications to a "moved" path.

User 1:
   svn co svn://server/repos/proj1/trunk p1
   cd p1
   vi f1.txt

User 2:
   svn co svn://server/repos/proj1/trunk p1
   cd p1
   svn mv f1.txt f2.txt
   svn commit -m "Renamed f1.txt to f2.txt"

User 1:
   svn update
   .... Adds file f2.txt ....
   .... Refuses to delete file f1.txt since it has local mods ....

   User 1 has to fix things up manually.

The question is, since svn knows about the ancestry of f2.txt,
couldn't (and shouldn't) it handle the operation in a completely
transparent manner? That is:

Use 1:
   svn update
   ... Moving f1.txt to f2.txt (with local mods) ...
   ... Merging f2.txt (nothing to merge) ...

Are there conseptual "gotchas" in such a behavior, or is it not done
merely due to implementation complexity? I believe svn has all the
information requitred to handle this. What I'm thinking off is
something like this:

   For every managed file in the wc:
     - If file was localy modified get a (conspetual) "patch" and
       remember it. This "patch" should include info like path
       deletion or path renaming.
     - Revert the file to its pristine state.
     - Apply any commited changes since the path's base (in order)
     - Apply the "remembered" patch, fixing the "source-name" to the
       new name of the path (if the name has changed).

I know I'm leaving a ton of details out, but you should get the
picture. How close is the current behavior of SVN to this?

Cheers
/npat

-- 
Sufficiently advanced political correctness is indistinguishable
from irony.
  -- Erik Naggum
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org