subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Shepelev <anton....@gmail.com>
Subject Re: Implementing the Lock->Edit->Unlock cycle
Date Thu, 29 Sep 2016 11:58:44 GMT
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.


Mime
View raw message