On Wed, Dec 24, 2008 at 8:34 AM, Ilan Yaniv
> From time to time, there is a reason to change the file and
> submit changes.
>
> So pre-commit can be a little to much….
Depends upon the pre-commit hook. For example, my pre-commit hook uses
a configuration file, so it is fairly simple to take a file in and out
of service:
[FILE Don't let users change this particular file]
file=^/file/location/in/repository/file\.name$
access=read-only
users=@ALL
This prevents users from making commits containing this particular
file. If I want to allow users to do so, I can do this:
;[FILE Don't let users change this particular file]
;file=^/file/location/in/repository/file\.name$
;access=read-only
;users=@ALL
Note the semi-colons in the front of the file names. This marks these
lines as comments in my control file. Now, users can commit the file.
Of course, someone will have to first notify me in order to make this
change in the control file, and I have to set it back after the
commit, but this really isn't an onerous task.
Even better is to do something like this:
[FILE Don't let users change this particular file]
file=^/file/location/in/repository/file\.name$
access=read-only
users=@ALL
[FILE Only managers can change this template]
file=^/file/location/in/repository/file\.name$
access=read-write
users=@managers
Now, managers (or you could name a specific user) can modify this
file, but not the average developers. So, when a change needs to be
made, a manager can do it without first contacting you. Then, you
don't even have to be in the loop.
Even better would be to make the file a "template", then allow
developers to copy the file, but not commit the file. Managers would
be able to change the template:
[FILE Don't let users change this particular file or the template]
file=^/file/location/in/repository/file\.name(\.template)?$
access=read-only
users=@ALL
[FILE Only managers can change the template]
file=^/file/location/in/repository/file\.name.template$
access=read-write
users=@managers
The only thing I'd also do is add a "svn:ignore" on the directory that
contains the file in order to ignore the non-template version. That
way, developers don't try to accidentally add it to the repository
when they do a "svn add -R *".
Of course, the pre-commit hook would simply fail any attempt to add
the non-template version of this file to the repository, but if I can
do something this simple to make developer's lives a bit easier, why
not?
The only way it could get easier than this is if your computer could
read minds and simply know when to make that file writable or not.
On Wed, Dec 24, 2008 at 8:34 AM, Ilan Yaniv <Ilan.Yaniv_at_timetoknow.org> wrote:
> So here is another catch.
>
> From time to time, there is a reason to change the file and submit changes.
>
>
>
> So pre-commit can be a little to much….
>
>
>
> Any other way ?
>
>
>
> ________________________________
>
> From: vishwajeet singh [mailto:dextrous85_at_gmail.com]
> Sent: Wednesday, December 24, 2008 3:32 PM
> To: Ilan Yaniv
> Cc: users_at_subversion.tigris.org
> Subject: Re: How can I set a file to be locked for check in, and R\W for
> check out?
>
>
>
> Implement a pre-commit hook which blocks all the commits to this file.
>
> On Wed, Dec 24, 2008 at 6:38 PM, Ilan Yaniv <Ilan.Yaniv_at_timetoknow.org>
> wrote:
>
> Hi
>
> I have this file that I want everybody to be aware that developers are not
> supposed be able to commit their changes.
>
> But on the other hand, this file should not be Read only because developers
> must make changes in their places to this file for debug reasons.
>
> But it they do check in to their changes, the build will crush.
>
> How can I set a file to be locked for check in and R\W for check out?
>
> Ilan Yaniv
>
> Configuration Management
>
> Phone: 03-7534333 ext. 5873
>
> Ilan.Yaniv_at_timetoknow.org
>
>
> --
> Cheers,
> Vishwajeet
> http://www.singhvishwajeet.com
--
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=991778
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2008-12-24 19:42:47 CET