You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nick Patavalis <np...@efault.net> on 2004/08/11 03:18:42 UTC

Local modifications to a "moved" path (again)

I was reading the subversion 1.1 release notes, and under the "Client
Follows Renames" section, it says:

  Subversion makes a lot of noise about the way branches (copies) of
  files and directories maintain historical connections to their
  source, but in Subversion 1.0 only 'svn log' actually follows that
  history, not 'svn diff', 'svn merge', 'svn list', or 'svn cat'.

  This problem (issue 1093) is now fixed in Subversion 1.1. All client
  subcommands now transparently trace backwards through renames when
  examining older versions of files and directories.

Does this means that an operation like the following will, under
1.1.x, be handled correctly?

  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 ...
    ... Deletes file f1.txt ...
    ... Merges local changes to "old" f1.txt to f2.txt ...

Regards
/npat


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Local modifications to a "moved" path (again)

Posted by Ben Collins-Sussman <su...@collab.net>.
Nick Patavalis wrote:

> Does this means that an operation like the following will, under
> 1.1.x, be handled correctly?

No.  It means that later on, if you run 'svn diff -r1 f2.txt', you won't 
get an error about "f2.txt not existing in r1".  Instead, the diff 
command will trace back through f2.txt's history, discover it was 
originally named f1.txt in r1, and use that file for comparison.

> 
>   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 ...
>     ... Deletes file f1.txt ...
>     ... Merges local changes to "old" f1.txt to f2.txt ...
> 

This scenario will never work until the client and server have "true" 
renames, not just copies+deletes.  It's most likely a requirement for 
implementing merge-tracking features.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org