Re: svnlook in pre-commit hook, delete operations copying directories

Hello Lieven,

On Friday 13 June 2008 22:59:52 Lieven Govaerts wrote:

> What happens here is that 'svn copy' takes the revision from your
> working copy target ('.'), copies that revision in the repository
> directly and then replaces all files that were changed on trunk after
> that revision on the tag.

This is true, but wasn't true with the old version of Subversion.

> If you (can) update your working copy
> directory to HEAD this should not happen.

I always did the same thing, except using different tag names and
comments:

svn update
svn copy -m "Release V00.00.06" \
    . \
    http://svn/svn/testproject/tags/V00.00.06

Nevertheless, recent svn versions deleted old, not yet existent files
in freshly added directories when copying.

But, since the last Subversion update from the openSUSE repositories
it magically works. Even a copy from a not up to date working
directory to a tags subdirectory works:

A tags/V00.00.11/
U tags/V00.00.11/bar.c

Somebody at Tigris, or any other developer, must either have been
listening to this mailing list, or (s)he had the same problem.

> I'm not sure when it was introduced. Which version of the client where
> you using previously?

Almost everything from 0.x through 1.5.0. But I think thge problem
first showed up with a 1.4.x version, not with the latest, still Beta
1.5.0.

> If svnmerge.py would support specifying rules for 'replaced' items,
> would that solve this issue for you?

Hmmm. I will now watch the "changed" output of svnlook for a while and
reenable svnperms.py as it is if the problem doesn't show up again.

Thanks for answering.

Roman

-- 
Roman Fietze  Telemotive AG  Büro Mühlhausen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org