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

Re: Allow copy files that already copied

From: Molle Bestefich <molle.bestefich_at_gmail.com>
Date: 2005-12-22 14:26:51 CET

Folker Schamel wrote:
> http://svn.haxx.se/users/archive-2003-12/0687.shtml

I agree with that particular posting.
Especially I think that this:

"Another practical aspect is that you cannot move
 a directory and then afterwards rename files within
 this directory without an intermediate commit."

is a very good point for supporting multiple cp/mv.

> (This discussion also goes into some details
> about the question what the right copy-from URL is.)

Haven't read the entire thread :-).

Since repository recording time is by definition the time when you do
'svn commit', any intermediate change in the working copy should not
be reflected. Only the final state of the working copy compared to
the previous state in the repository should be reflected in the
commit.

With that in mind, I don't imagine it's hard to define what the
correct copy-from should be. Or is it?

> Especially I think that the scenario I described in
> http://svn.haxx.se/dev/archive-2005-01/0358.shtml
> is a good reason for supporting it.

I don't think so, the whole premise of the scenario is false.
TortoiseSVN supports moving foo/foo.cpp -> tau/tau.cpp just fine.
Just right-click foo.cpp, select "Rename..." then enter "../tau/tau.cpp".

(The menu item should probably be renamed to "Move/Rename ..." to
lessen confusion.)

> An old discussion about this topic:
> http://svn.haxx.se/dev/archive-2005-01/0339.shtml

Interesting.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 24 23:57:24 2005

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.