Mathias.Weinert@gfa-net.de writes:
> > files to be deleted but the new ones not created. Also, I am
> > surprised that the old directory tree still exists (despite the fact
> > that it is empty excpet the .svn directories).
>
> That's normal behavior. Subversion still has the
> information that this folder is scheduled for deletion
> in the .svn folder.
OK, I thought something like that could be the reason, although I
would expect this information to be in the .svn directory in that
directory, in which the directory to be deleted is located. If find
it bit annoying to have the directory still hanging around in my
working copy after deleting it.
> You normaly can't damage the repository by doing a
> commit. If you delete something wrong with a commit
> you can always ressurect the old revision.
My use of the word "damage" here was misleading, sorry. I meant I
didn't want to risk to check in wrong changes which then would annoy
other developers in the project and which had then to be fixed.
> You may want to have a look at
> http://svn.haxx.se/dev/archive-2006-02/0853.shtml
> where I described exactly what you see here.
Yes, the inconsistency you describe there is what made me wonder, if
the check-in would do want I want/expect, and what let me ask here.
> In short: Subversion just shows one line for the whole
> tree. If you say 'svn st' you will see a '+' near the 'A'
> which shows that the new folder isn't only added but
> copied from another folder. (And if you commit the change
> you will see only one line for the deleted folder, too.)
I did indeed see the '+' and I actually thought it could be the
indication, that the check-in would do the right thing. But then I
did the 'svn diff' and it showed only the deleted files but not the
added files, which really surprised me. I expected the 'svn diff'
coammd to produce output that coould be used as input for patch to get
from the old revision to the new one which I was about to check in.
This is then obviously not so.
I will do some more experiments on a local repository to get some more
insight on this.
> Please be aware that in your example you don't rename
> can to net but move can to net/can. If you want to rename
> can to net you mustn't create net before doing the move.
Yes, I know. Just like the Unix commands "mv foo bar" and "mkdir bar;
mv foo bar". I really wanted to move one dir down, not only rename.
urs
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 27 12:51:05 2006