You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Greg Long <su...@glong.info> on 2011/02/15 18:33:09 UTC

Folder-based properties

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

Re: Folder-based properties

Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Greg Long,
am Mittwoch, 16. Februar 2011 um 20:09 schrieben Sie:

> The files are basically csv files. The software that is used to open
> them will make random (and innocuous) changes to one of its internal
> columns.

> So every time the software is run, the files are marked as changed
> when nothing has really changed. If the files are marked read-only,
> the software respects that and functions just fine.

As you use TortoiseSVN, did you look at client side scripts? You can
run them before/after commits and updates and it should be easy to
just set the files read only with a script. Everyone has to update, so
this should work, depending on what you mean with just copying your
branches to a release directory, the commit or even update script
should fire as well. If you copy using Tortoise's archive explorer the
one who created the release needs to update to, if you copy locally
one needs to commit and this script should fire.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoening@am-soft.de
Web:     http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow


Re: Folder-based properties

Posted by Greg Long <su...@glong.info>.
2011/2/16 Thorsten Schöning <ts...@am-soft.de>:
> Guten Tag Greg Long,
> am Mittwoch, 16. Februar 2011 um 13:15 schrieben Sie:
>
>> I think you misunderstand. It is OK for all authorized users to commit
>> releases. What I am trying to accomplish is to make all files in a
>> working copy of a release branch read-only.
>
> Just for my interest, but what is the use case you're trying to
> accomplish? In the end every developer can clear read only attributes
> in his working copy as will. Is the benefit that Windows Explorer, an
> editor etc. shows error message whenever one tries to edit the files?
> Is it for some kind of build process?

The files are basically csv files. The software that is used to open
them will make random (and innocuous) changes to one of its internal
columns.

So every time the software is run, the files are marked as changed
when nothing has really changed. If the files are marked read-only,
the software respects that and functions just fine.

This is something that we have to deal with in the development copies,
but would like to insulate the users from this annoyance.

We make extensive use of svn:externals where most of the externals are
released copies. When the user commits their local changes, the
changed external releases will cause the commit to fail.

Greg
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning
> AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
>
> Telefon: Potsdam: 0331-743881-0
> E-Mail:  tschoening@am-soft.de
> Web:     http://www.am-soft.de
>
> AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
> Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
>
>

Re: Folder-based properties

Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Greg Long,
am Mittwoch, 16. Februar 2011 um 13:15 schrieben Sie:

> I think you misunderstand. It is OK for all authorized users to commit
> releases. What I am trying to accomplish is to make all files in a
> working copy of a release branch read-only.

Just for my interest, but what is the use case you're trying to
accomplish? In the end every developer can clear read only attributes
in his working copy as will. Is the benefit that Windows Explorer, an
editor etc. shows error message whenever one tries to edit the files?
Is it for some kind of build process?

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoening@am-soft.de
Web:     http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow


Re: Folder-based properties

Posted by Greg Long <su...@glong.info>.
2011/2/16 Thorsten Schöning <ts...@am-soft.de>:
> Guten Tag Greg Long,
> am Dienstag, 15. Februar 2011 um 18:33 schrieben Sie:
>
>>  - Files in release directories must not be changed or deleted.
>>  - Files in template directories must not be copied.  They should be
>>    extracted instead.
>
> Doesn't this sound like it should be handled with per directory
> permissions using authz? The only problem is to create Rel/A10 for the
> first time, right? So give Rel normal write access, let A10 be created
> and write new read only permissions for A10 to authz using a post
> commit hook. The hook just needs to know that it have to do so with
> all folders created in Rel, which should be easier than your logic for
> a pre-commit hook sounded.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>

I think you misunderstand. It is OK for all authorized users to commit
releases. What I am trying to accomplish is to make all files in a
working copy of a release branch read-only.

It seems to me that the easiest way to accomplish this is through
svn:needs-lock. The files will never actually be locked because they
can never be committed, but when checked out, they will be made
read-only.

I am looking for a way to enforce the svn:needs-lock requirement when
releases are created. If the files are committed, this is easy. The
problem arises when a development branch is copied into a release
branch. In this case, the files will not have the required
svn:needs-lock property. I could prevent copying any directory into a
release branch, but I was hoping for a more user-friendly solution.

Re: Folder-based properties

Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Greg Long,
am Dienstag, 15. Februar 2011 um 18:33 schrieben Sie:

>  - Files in release directories must not be changed or deleted.
>  - Files in template directories must not be copied.  They should be
>    extracted instead.

Doesn't this sound like it should be handled with per directory
permissions using authz? The only problem is to create Rel/A10 for the
first time, right? So give Rel normal write access, let A10 be created
and write new read only permissions for A10 to authz using a post
commit hook. The hook just needs to know that it have to do so with
all folders created in Rel, which should be easier than your logic for
a pre-commit hook sounded.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoening@am-soft.de
Web:     http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow


Re: Folder-based properties

Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Tue, Feb 15, 2011 at 12:33 PM, Greg Long <su...@glong.info> wrote:
> 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.

Put those "templates' in a separate repository, and derive the content
of them with "svn:externals" or a build process that exports their
content. This will break the ability to "svn copy" them. You you then
get things to the template is a separate issue.

Personally, I think this is silly: if you can't copy the templates,
you can't bring along their history or their Subversion properties,
such as EOL format or svn:keywords. But it's your environment..

Re: Folder-based properties

Posted by Kevin Grover <ke...@kevingrover.net>.
You could create a custom property on the directory (svn ps glong:released
'WHATEVER INFO YOU WANT') and then
and have a pre-commit hook that looks for the present of that property and
refuses commits to those directories.  You could also set attributes to
read-only, but if they can't commit, it really doesn't matter.

I just plucked 'glong' from your email address: use something unique to your
company name (NOT svn: tsvn: etc...)

On Tue, Feb 15, 2011 at 09:33, Greg Long <su...@glong.info> wrote:

> 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
>