On 20.05.06 19:02:36, Sergio Bossa wrote:
> On 5/20/06, Ryan Schmidt <subversion-2006q2@ryandesign.com> wrote:
>
> >I can't imagine why you
> >wouldn't in real use replace the above three commands with "svn mv
> >test_file test_file_rn".
>
> Doing an add and replace should be exactly the same as doing a move.
> In fact, the same problem still appears when doing a pure move operation.
No, the difference is that svn mv tells subversion to move the history
of that file, while when doing a svn delete and an svn add afterwards
you get 2 different files in the repository and nobody will know that
test_file_rn is the same as test_file only with a different name.
> >To avoid the problem below, you will want to do an "svn update" at
> >this point.
>
> This seems to solve the problem!
> The update seems to have no effect, but then the problem doesn't
> appear ... why do we need to make an update?
I guess this has to do with subversions global version numbers. Say you
have a working copy in directory wc and a file foobar in it. When you do
a svn commit foobar, foobar in your working copy is at the "newest"
revision, however . (the working copy directory) is still on the old
revision, you can easily check with svn info. You need to update ., even
though this will just update svn's 'metadata'. I don't have the list of
commands at hand, but IIRC you deleted a file in a subdir of the working
copy, did an svn commit . (the . is implicit if you don't give a name)
in that subdir and later changed something in the working copy (a mv
IIRC?), so you stepped in to that trap. The working copy was not
up-to-date.
Andreas
--
You are going to have a new love affair.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 20 19:38:55 2006