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.
