You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Anton Shepelev <an...@gmail.com> on 2016/09/28 15:46:24 UTC
Implementing the Lock->Edit->Unlock cycle
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.
Re: Implementing the Lock->Edit->Unlock cycle
Posted by Eric Johnson <er...@tibco.com>.
On 9/29/16 4:58 AM, Anton Shepelev wrote:
> Thanks to everybody for their replies.
>
> Eric Johnson to Anton Shepelev:
>
>
>> "svn update" is your friend. Just encourage users
>> to do updates before they start editing.
> Is there no protection against an oblivious users's
> losing a day's work merely because he forgot to up-
> date his working copy, which was obsolete beyond
> merging?
Your best protection against this problem - which can happen with any
version control system, is to keep developers updating and committing
regularly. A developer who goes off in a corner for two weeks, then
produces a massive change can disrupt under any system. The "exclusive
lock" behavior of VSS and others prevents some aspects of that, but not
others. Reminding your team to both update and commit regularly will
probably solve the problem. For a similar reason, long-term branches can
be quite tricky to manage.
>> Also, the lock-before-edit approach doesn't actual-
>> ly solve the problem of making sure users have the
>> latest. My recollection from using VSS was that
>> integration problems showed up more frequently, not
>> less. I think this was from the illusion that I
>> have the latest version of the file I want to edit
>> (since I got the lock), so my files are probably
>> all going to be consistent.
> VSS guarantees that you are editing the latest ver-
> sion of the file, unless, of course, you have ex-
> plicitly overriden the readonly attribute. The oth-
> er files, both dependent and depending, may be obso-
> lete though.
Exactly. My point was merely that from my recollection, the switch from
VSS to Subversion, counter-intuitively, led to fewer conflicts, all
easier to resolve, not more.
>> I suspect you could tie yourself up into knots try-
>> ing to write hook scripts that accomplish some of
>> what you want, ->
> I hope hooks are not that hard...
In principle, they're quite straightforward to write the first time. It
is my experience that once you have a server running in production,
changing the hook scripts gets tricky fast. You don't want to disrupt
people with downtime, you need to test them, and weird corner cases
emerge. Especially as the number of repositories you support goes up,
and clients ask for different behavior across the repositories.
One way to avoid some of those problems - use / implement "web" hooks,
where the post-commit or pre-commit logic lies off the server, and can
be maintained independently of the server itself.
>
>> -> but by the time you get them working just the
>> way you think you want them, you'll discover that
>> you probably don't want them that way.
> Maybe, but I am under peer pressure, and TFS is the
> alternative, and I think we still need it at least
> for "binary" files such as MS Word documents. I
> wish we maintained documentaion in Texinfo, LaTeX,
> of Troff, but am helpless in this regard.
Yes, for stand-alone binary files like MS Word docs, the Subversion
locks are perfectly fine. The challenges with locks emerge when applied
to documents like source code - where the files are inter-related. My
suggestion - trust in Subversion for text files, and only use locks for
frequently changing binaries.
Eric.
Re: Implementing the Lock->Edit->Unlock cycle
Posted by Anton Shepelev <an...@gmail.com>.
Andreas Krey:
>If you plan doing massive work in a module, you
>need to talk to the other people working in the
>same module anyway, as they would be annoyed if you
>locked the file, and they can't do planned work.
OK.
>Ideally the other people do their commits in small
>increments as well, and you could go and try to
>merge their work to see if that works or starts to
>fall apart. (Even more ideally you'd get notifica-
>tions if other people commit changes that happen in
>parallel to yours, and will need to be merged.)
Those could be implemented via hooks, but how shall
one determine whether a person is currently working
on some file or not, lest he be swarmed by irrele-
vant notifications?
>>As I understand, it requires customization of the
>>svn client so that whenever asked to unlock a file
>>it shall update it also. Is it possible?
>
>No. SVN clients may not even be online at that
>time. Also I would seriously *not* want files to
>change in my workspace e.g under a test run.
But I meant that for locks issued locally via the
working copy.
>Actually, we use svn for such purposes (non-mer-
>gable files), and git for regular sources.
So do you always update and then lock while commenc-
ing work on a non-mergeable file, or do you invoke
this sequence via a single mouse-click or a key-
press?
--
Please, do not send replies to the list to my e-mail.
Re: Implementing the Lock->Edit->Unlock cycle
Posted by Andreas Krey <a....@gmx.de>.
On Thu, 29 Sep 2016 14:58:44 +0000, Anton Shepelev wrote:
...
> Is there no protection against an oblivious users's
> losing a day's work merely because he forgot to up-
> date his working copy, which was obsolete beyond
> merging?
He will learn it, lucky eddie style.
If you plan doing massive work in a module, you
need to talk to the other people working in the
same module anyway, as they would be annoyed if
you locked the file, and they can't do planned work.
Ideally the other people do their commits in small
increments as well, and you could go and try to
merge their work to see if that works or starts
to fall apart. (Even more ideally you'd get
notifications if other people commit changes
that happen in parallel to yours, and will need
to be merged.)
...
> I should like svn to update the local copy automati-
> cally once the lock is issued, but it seems impossi-
> ble via server-side hooks, for they don't have ac-
> cess the user's woking copy where the file must be
> updated.
If you want such things you should visit clearcase,
with their basically-mandatory central file server.
...
> time it is locked? As I understand, it requires
> customization of the svn client so that whenever
> asked to unlock a file it shall update it also. Is
> it possible?
No. SVN clients may not even be online at that time.
Also I would seriously *not* want files to change
in my workspace e.g under a test run.
...
> Maybe, but I am under peer pressure, and TFS is the
> alternative, and I think we still need it at least
> for "binary" files such as MS Word documents.
Actually, we use svn for such purposes (non-mergable files),
and git for regular sources. Unfortunately I'm not the
svn side admin, so I can't tell how they do the locking.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Implementing the Lock->Edit->Unlock cycle
Posted by Anton Shepelev <an...@gmail.com>.
Thanks to everybody for their replies.
Eric Johnson to Anton Shepelev:
>>> 1. lock and update,
>>> lest one might accidentally start editing an
>>> old version of some file.
>
>Subversion supports locks. However, it sounds like
>they do not work the way you want them to.
>
>Subversion's locks do not prevent anyone from edit-
>ing files. They merely slow other people, besides
>the owner of the lock, from committing changes.
But the svn:needs-lock property helps somewhat.
>"svn update" is your friend. Just encourage users
>to do updates before they start editing.
Is there no protection against an oblivious users's
losing a day's work merely because he forgot to up-
date his working copy, which was obsolete beyond
merging?
I should like svn to update the local copy automati-
cally once the lock is issued, but it seems impossi-
ble via server-side hooks, for they don't have ac-
cess the user's woking copy where the file must be
updated. If am right about it, is there any mecha-
nism to cause SVN to update the local file every
time it is locked? As I understand, it requires
customization of the svn client so that whenever
asked to unlock a file it shall update it also. Is
it possible?
>Also, the lock-before-edit approach doesn't actual-
>ly solve the problem of making sure users have the
>latest. My recollection from using VSS was that
>integration problems showed up more frequently, not
>less. I think this was from the illusion that I
>have the latest version of the file I want to edit
>(since I got the lock), so my files are probably
>all going to be consistent.
VSS guarantees that you are editing the latest ver-
sion of the file, unless, of course, you have ex-
plicitly overriden the readonly attribute. The oth-
er files, both dependent and depending, may be obso-
lete though.
>In practice, other developers change APIs, and I
>only discover that by keeping current on the latest
>code changes.
That may happen, but it is only one half of the
proglem, and actually less than that in my case,
where the interfaces change less frequently than the
implementations, which is a good thing.
>>> 2. commit and unlock.
>>Commits and locks are independent.
>
>Commits and locks are independent.
In SVN's inteded process, yes, but they are not in
the lock-edit-unlock cycle.
>I suspect you could tie yourself up into knots try-
>ing to write hook scripts that accomplish some of
>what you want, ->
I hope hooks are not that hard...
>-> but by the time you get them working just the
>way you think you want them, you'll discover that
>you probably don't want them that way.
Maybe, but I am under peer pressure, and TFS is the
alternative, and I think we still need it at least
for "binary" files such as MS Word documents. I
wish we maintained documentaion in Texinfo, LaTeX,
of Troff, but am helpless in this regard.
--
Please, do not send replies to the list to my e-mail.
Re: Implementing the Lock->Edit->Unlock cycle
Posted by Eric Johnson <er...@tibco.com>.
Hi Anton,
On 9/28/16 8:46 AM, 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.
Subversion supports locks. However, it sounds like they do not work the
way you want them to.
Subversion's locks do not prevent anyone from editing files. They merely
slow other people, besides the owner of the lock, from committing changes.
"svn update" is your friend. Just encourage users to do updates before
they start editing.
Also, the lock-before-edit approach doesn't actually solve the problem
of making sure users have the latest. My recollection from using VSS was
that integration problems showed up more frequently, not less. I think
this was from the illusion that I have the latest version of the file I
want to edit (since I got the lock), so my files are probably all going
to be consistent. In practice, other developers change APIs, and I only
discover that by keeping current on the latest code changes.
The Subversion approach quickly trains users to get the latest changes
frequently.
> 2. commit and unlock.
Commits and locks are independent.
>
> Can SVN be configured to have such operations, and
> how?
I suspect you could tie yourself up into knots trying to write hook
scripts that accomplish some of what you want, but by the time you get
them working just the way you think you want them, you'll discover that
you probably don't want them that way.
Eric.
>
> We plan to use it mainly from the AnkhSVN plugin for
> Visual Studio, but I think the question belongs
> here.
>
Re: Implementing the Lock->Edit->Unlock cycle
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Sep 28, 2016 at 11:46 AM, Anton Shepelev <an...@gmail.com>
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?
>
See these sections of the book:
http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.vsn-models
http://svnbook.red-bean.com/en/1.7/svn.advanced.locking.html
and particularly this section:
http://svnbook.red-bean.com/en/1.7/svn.advanced.locking.html#svn.advanced.locking.lock-communication
Locking a file will not force an update to happen, but the lock itself is
not held on any specific revision either.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Implementing the Lock->Edit->Unlock cycle
Posted by Stefan Hett <st...@egosoft.com>.
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
Re: Implementing the Lock->Edit->Unlock cycle
Posted by Anton Shepelev <an...@gmail.com>.
Lorenz to Anton Shepelev:
>>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.
>>[...]
>
>"svn lock" will fail if your working copy is not up
>to date.
>
>So using svn:needs-lock and an editor that prevents
>you from modifying read-only files should do the job.
Thanks.
--
Please, do not send replies to the list to my e-mail.
Re: Implementing the Lock->Edit->Unlock cycle
Posted by Lorenz <lo...@yahoo.com>.
Anton Shepelev wrote:
>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.
>[...]
"svn lock" will fail if your working copy is not up to date.
So using svn:needs-lock and an editor that prevents you from modifying
read-only files should do the job.
--
Lorenz