On 9/28/2016 5:46 PM, Anton Shepelev wrote:
Hello, all

We  are migrating to SVN from the dreaded SourceSafe
and should like to retain, if only at the start, the
exclusive  check-out  process,  with  the  following
*atomic* operations which  should  be  performed  as
easily as possible:

   1.  lock and update,
       lest  one  might accidentally start editing an
       old version of some file.

   2.  commit and unlock.

Can SVN be configured to have such  operations,  and
how?

We plan to use it mainly from the AnkhSVN plugin for
Visual Studio, but  I  think  the  question  belongs
here.
I honestly suggest you drop that whole VSS concept of locking and unlocking files. In my current job I migrated us from VSS to SVN around 8 years ago. Those who only knew VSS before and got used to the problem of working with locked files had really heavy concerns about a system not relying on locks (and the potential problems with resolving/handling conflicts upon merges). It took them only around 2-3 days to realize that the way SVN works is way better than the lock/unlock style and all their concerns went away before the end of the week.

That said: I really suggest you go the direct way and not use the lock/unlock workflow anymore. Maybe suggest to try it for a week at least and if it really causes concerns/problems in your case you can restore the lock/unlock process without much trouble at that point.

If you still want to stay with locks, then yes, it's possible. Users can lock files (and therefore indicate that they are working on these), commit their change and unlock the file again. Note that out of the box SVN won't require a file to be locked before commit however (but if it is, you can't commit it without removing the lock first). You should be able to prevent commits without a prior lock however (via the pre-commit hook) and you could also automate unlocking of locked files upon commit (via the post-commit hook), if that's really something you need to do.

As far as I know you can also ensure that a lock is only removed by an authorized user, via the pre-unlock-hook.

--
Regards,
Stefan Hett

Reply via email to