[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Folder-based properties

From: Greg Long <subversion_at_glong.info>
Date: Tue, 15 Feb 2011 12:33:09 -0500

Hi,
I am supporting a Subversion repository that has a some interesting
requirements.

 - Log message minimum length.
 - Files in release directories must not be changed or deleted.
 - Files in template directories must not be copied. They should be
   extracted instead.

These I have all dealt with in a Python-based pre-commit hook.

I am stuck on one last requirement. All files in release directories
should have the svn:needs-lock property. The real goal is not the
svn:needs-lock property, but the read-only status when a release
version is checked out.

All released files are placed somewhere under a directory named
Rel, e.g., .../Rel/A10/20100215/ReleasedFiles.txt

My first attempt was to force it in the pre-commit hook. This did not
work, because to create a release, we just copy a development branch
to a release directory. That means no files are changed, so the
pre-commit hook does not get a chance to change, or even check for,
the svn:needs-lock property.

I also tried experimenting with the tsvn:autoprops property, but that
was also unsuccessful.

I have come up with 2 solutions, but I am looking for a better one.
 1) Do not allow directories to be copied into release directories.
    This would force the user to actually commit files.
 2) Use the script add-needs-lock.py which can do exactly what I need.
    The problem is that it takes several minutes to run, so it cannot
    be run during the commit process. This leaves open the possibility
    (probability) that a release version could be checked out but the
    files not marked read-only.

Client: primarily TortoiseSVN 1.6.1x
Server: Apache 2.2 with svn 1.6.6? running on Windows XP

Any assistance would be appreciated.

Thank you,
Greg
Received on 2011-02-15 18:34:29 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.