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 sales@march-hare.com.
John J. Xenakis wrote: > >>> Exclusive edit locks > > I want the restriction that only one person at a time can edit any > given file to be strictly enforced (even for text files). All the > documentation I've read is very disparaging of this model, often even > contemptuous, but it's still what's needed for this group on this > project. Are you sure? Why? > I hope I have this right (since it needs further testing), > but I've settled on the following to accomplish this for a given new > "Project": > > cvs co Project > cd Project > cvs watch on > cvs commit > cvs unedit Hmm, do you really understand what this does? For instance what's the point of unediting if you did not run edit in the first place? And "cvs watch on" is basically just "Always checkout files read-only" enforced from the server side. Thus it especially doesn't make sense to run this *after* you have already checked out the project (unless that sequence of commands was run before by someone else). There are several other approaches for enforcing reserved edits: (Don't use edit -x or the -kx option. If you do that you could just as well stick with SourceSafe.) - If you really want to enforce this for all files in your repository (not recommended), then simply put the following three lines into your CVSROOT/cvsrc file: cvs -r edit -c commit -c - If you only want the reserved model to apply to individual files (recommended), specify them in the CVSROOT/cvswrappers file in the following way (example): *.doc -kBc *.txt -kc A potential downside of this approach is that it could accidentally be overridden if users use frontends that explicitly add binary files using -kb - You would have to make sure that the file flag handling for newly added files is entirely left to the server. Not really sure how to enforce this, though... [Idea: Tony, would it be possible to put something like the following into cvswrappers so that clients could still add as -kb? *.doc -k+c ] > >>> Using POSTCOMMAND triggers > > I guess the easiest way to maintain a shadow repository is the > following, which I've tried and found to work: Are you aware that CVSNT already comes with a ready-to-use solution to this? I haven't tried it in practice yet but in theory all you should have to do is enable the "Automatic Checkout" plugin and set up the CVSROOT/shadow file. > >>> Shadow repository on a share > > I'm fairly certain that at some point the client is going to ask me > to move the shadow repository to a shared disk. I understand that > this idea is treated with disdain and contempt by the CVSNT community, > but I believe that the client is going to request this. As long as that "shadow sandbox" is read-only and is never used to commit from there shouldn't be too much of a problem I think. Cheers, -- Oliver ---- ------------------ JID: ogiesen at jabber.org ICQ: 18777742 (http://wwp.icq.com/18777742)