Re: calling svn copy twice...

On Wed, Dec 8, 2010 at 6:26 AM, Michael Kessler <kessler.michael_at_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_at_gmail.com