Well, yes and no. You could do that, but
svn mv old_name new_name
*should* also work.
You *should* be able to do this in a working copy. Working locally is always preferable to working directly on the repository, as you can test your changes before you commit them. In addition, if that rename is going to be in conjunction with other changes (such as changing relative paths in makefile or for included files) then it would be preferable to have all those changes in a single change set and single commit.
A rename is currently a copy (add with history) and a delete. I believe that better rename behaviour is planned.
SVN will (or should) never destroy information, even in your working copy. Perhaps you are seeing a result of that. For example, reverting an added file (without history) only reverts the act of adding, but does not delete the file. I'm not sure what is the problem in your case.
Could you (Rob) show the commands you're giving and the responses from SVN? Perhaps you could provide a little more detail, preferably a cut down demonstration of the behaviour you're seeing. If you could demonstrate the problem with just a few files and directories, it might be clearer. Someone on the mailing list might then be able to provide more help...
(another) Rob.
-----Original Message-----
From: Sivakumar Gopalan [mailto:sivakumar@collab.net]
Sent: 06 September 2006 19:09
To: Rob Wilkerson; Subversion Mailing List
Subject: RE: Copy/Move/Rename Failing
You can try doing it directly in the repository instead of doing it in
the working copy.
svn mv <repository full path> <repository full path>
Eg:
svn mv http://svn.collab.net/repos/svn/branches/xxx
http://svn.collab.net/repos/svn/branches/xxy
-siva
> -----Original Message-----
> From: Rob Wilkerson [mailto:r.d.wilkerson@gmail.com]
> Sent: Wednesday, September 06, 2006 11:10 PM
> To: Subversion Mailing List
> Subject: Copy/Move/Rename Failing
>
> I'm not sure if this is a misunderstanding on my part, but I'm trying
> to rename a directory which contains a lot of files and
> subdirectories) which, as I understand it, is essentially 2
> operations: copy and delete. It looks like the copy part works fine
> in terms of moving all of the subdirectories and files, but the newly
> copied directory is retaining the "Normal" status. That leaves me
> with a new folder by the new name that thinks it's checked out from a
> repository which doesn't know it exists. I've tried to create the new
> directory via rename and I also tried to do a basic copy.
>
> I've tried these operations via TSVN and the command line (WinXP). In
> all cases, I get an error that a file (which file varies) in a .svn
> subdirectory of the new copy is locked. Since it's the newly copied
> directory, I assume this means that the process itself is locking it.
>
> Has anyone else seen this? Am I doing something wrong? Any insight
> would be appreciated.
>
> Thanks.
>
> --
>
> Rob Wilkerson
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
_____________________________________________________________________
This incoming message has been checked for all known viruses by the Messagelabs Scanning System, on behalf of Celoxica Ltd.
_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd.
This email and any files transmitted with it are confidential and
may be legally privileged. It is intended solely for the use of the
individual or entity to whom it is addressed. If you have received
this in error, please contact the sender and delete the material
immediately. Whilst this email has been swept for viruses, you
should carry out your own virus check before opening any
attachment. Celoxica Ltd accepts no liability for any loss or
damage which may be caused by software viruses or interception
or interruption of this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 7 13:07:32 2006