[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Copy/move-handling on update in 1.5

From: Tor Ringstad <torhr_at_pvv.org>
Date: 2007-11-15 13:48:50 CET

[Mark Phippard <markphip <at> gmail.com>]
> I am not sure if this is predictable via filename. You could do:
> svn mv file2 afile2
> And see if that is different.

I've experimented a bit, but I'm not able to construct any scenario
where an add comes before the delete. In fact, it almost looks like
*all* deletes always comes first, then *all* adds (for pure renames,
that is).

> Moving a file from a subdir into its parent should do it.

Well, just sort of. I redid the test from my initial post, but instead
of just plainly renaming the file, i moved it out of a subdir.

Initial setup is a directory "dir" with a single empty file "file",
and two up-to-date working copies.


  # Move file

  % svn mv dir/file .
  A file
  D dir/file
  % svn commit -m "moved"
  Deleting dir/file
  Adding file
  Committed revision 128.


  # Modify local file, get move via update

  % echo foobar >> dir/file
  % svn st
  M dir/file
  % svn up
  A file # note #1
  D dir/file
  Updated to revision 128.
  % svn st
  ? dir/file
  % cat file
  % cat dir/file

Now the add actually comes before the delete (note #1), but the local
modifications are still "lost" in the now unversioned dir/file.

So I'm kind of back to my initial question; are there actually any
examples of the "Improved copy-handling during updates" functionality
that is described in the release note:


Is this text perhaps promising a bit much? I have to say I got high
expectations after reading it, and I'm sure a lot of others will as

- Tor Ringstad -

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 15 13:49:18 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.