--Noam Tamim <noamtm@gmail.com> wrote:
> Our svn repository contains files (VS.Net project files) that must not be
> edited by more than one user simultaneously (merging them makes no sense).
> For these files, we want to work in a SourceSafe-like mode.
>
> 1. What's the correct way to do it? I'm sure we're not the first svn users
> to come across this problem, so possibly there's a configuration item for
> that.
>
> 2. As an attempt to solve this problem, we added the needs-lock property
> to these files - so that they are read-only until a user requests the
> lock. The problem is that if a user manually resets the read-only flag on
> the file, he can change it and then commit - without first acquiring a
> lock. I read that we can use the hook scripts for that - but the
> start-commit and pre-commit hooks don't pass the file and its state to
> the script, so it can't verify the commit. Am I missing something?
If User A has a file locked, User B cannot commit the file. This behavior
does not depend on the needs-lock property. (You can lock files that do not
have the needs-lock property set.) The needs-lock property makes the file
read-only to act as a warning for users, indicating that they should lock
the file before making changes.
In addition to setting the needs-lock property on your VS.Net files, you
can implement a post-lock hook that emails your group whenever a file is
locked or unlocked. For our group I set up a simple python script to do
this.
> 3. It's also possible that we totally miss the purpose and usage of locks;
> we've been using SourceSafe so far, so please understand (and explain) :-)
I'm fairly new to version control in general and Subversion in particular,
but I believe that for code (text) files merging is recommended (people can
be more productive), but for binary files locking makes sense. So it sounds
like you are on the right track.
--
Bruce Webber
brucewebber@fastmail.us
http://brucewebber.us
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 2 00:30:05 2005