Re: Copy/move-handling on update in 1.5

[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.

WC2:

  # Move file

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

WC1:

  # 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
  <empty>
  % cat dir/file
  foobar

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:

  http://subversion.tigris.org/svn_1.5_releasenotes.html#leverage-copyfrom

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
well.

- 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