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.
Received on 2016-09-29 18:17:32 CEST