You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Michael Kessler <ke...@gmx.net> on 2010/12/08 11:26:39 UTC

calling svn copy twice...

Hi,

during tests with hudson my release build script was accidentally called
more than once. The script calls svn copy too.

1. svn copy file:///var/repo/prj/trunk file:///var/repo/prj/tags/V1 -m
"created V1"

In the Repo:
../prj/tags/V1/test.txt 
OK

2. svn copy file:///var/repo/prj/trunk file:///var/repo/prj/tags/V1 -m
"created V1"

In the Repo:
../prj/tags/V1/trunk/text.txt ????

I don't understand this behaviour. I expect an error message.

3. 2. svn copy file:///var/repo/prj/trunk file:///var/repo/prj/tags/V1
-m "created V1"

:~/svn: Path tags/V1/trunk already exists

I tried it with:

Windows XP SP3
CollabNet Subversion Command-Line Client v1.6.15

Ubuntu 10.04
svn Version 1.6.6 (r40053)

Regards 
Michael
   




Re: calling svn copy twice...

Posted by David Weintraub <qa...@gmail.com>.
On Wed, Dec 8, 2010 at 6:26 AM, Michael Kessler <ke...@gmx.net>wrote:

> 1. svn copy file:///var/repo/prj/trunk file:///var/repo/prj/tags/V1 -m
> "created V1"
>
> In the Repo:
> ../prj/tags/V1/test.txt
> OK
>
> 2. svn copy file:///var/repo/prj/trunk file:///var/repo/prj/tags/V1 -m
> "created V1"
>
> In the Repo:
> ../prj/tags/V1/trunk/text.txt ????
>
> I don't understand this behaviour. I expect an error message.
>

With the Unix cp command, if you're copying a file, and a directory of that
name already exists, the file is copied to that directory. The directory is
not replaced. Same behavior happens with a directory if you use "cp -r".

Actually this default behavior is better than if you actually did replace
your tags files. Imagine the mess that ensues if the entire directory got
accidentally replaced. Now, to fix, you only have to delete that
one extraneous directory, and none of your tagged files were touched.

There are a variety of pre-commit hooks that can take care of this issue.
These same hooks can also protect your tags from changing once created.

For example, I configure my pre-commit hook this way:

file: **/tags/**
access: read-only
users: @ALL

file: **/tags/*
access: add-only
users: @ALL

The first prevent users from modifying any files under "tags", and the
second permits copying directories only directly under the "tags" directory
which is what you'd do if you were actually creating a tag. This would have
prevented your script from doing what it did.

-- 
David Weintraub
qazwart@gmail.com