Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to firstname.lastname@example.org.
This is sort of a cross-posting as I posted virtually the same message to the cvsgui group, but I think this is the right forum for the discussion... At issue (for me anyway) is whether edit -c is sufficient for controlling access to non-mergable files (Word, gifs, etc). Anyway here's most of what I posted to the cvsgui group. Please let me know if I'm missing something! ---------- Suppose the case where one person (say Bob) does the right thing and uses edit -c (of course assuming the file is a binary), then someone else (Sue) comes along and forgets that they are supposed to do the -c and just does edit. Then they both are happily editing the file and whoever commits first "wins" (really they both lose). In the olden days when people had to lock with admin -l then if Bob does the admin -l and Sue forgets then she can still edit, but can't commit. She wasted her time, but Bob doesn't have to pay which seems more fair than "first in wins". That all being said... there's another case where Bob (the first person) forgets and just does a edit instead of edit -c, but Sue comes along later and remembers. In this case everything is fine as Sue will not be able to complete the edit -c since Bob is listed as an editor. This is better than the old admin -l result because in that case both Bob & Sue could edit the file even though only Sue could commit. Net result - in my mind both schemes are error prone, but with the old way I could institute procedures to improve the odds (i.e. tell people to use edit and check for editors AND use admin -l). Now I can't do that anymore (with CVSNT and WinCVS 1.3). To fix it I believe the server has to be involved to prevent any edit (and commit) no matter what, whenever someone has indicated they want a reserved edit. So... can someone provide insight into why edit -c was done the way it was and why admin -l was deprecated? That might at least help me understand when it is applicable. Also - is there any thoughts toward bringing admin -l back (or something similar that preferably didn't require admin group priveledges)? Thanks, - Rick