subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <e...@tibco.com>
Subject Re: Implementing the Lock->Edit->Unlock cycle
Date Thu, 29 Sep 2016 16:17:26 GMT
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.



Mime
View raw message