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.
Dear Oliver, > Are you sure? Why? [Re: Exclusive edit locks] Because it's confusing for the naive user and provides no benefit to the client, the way it would for a large software development group. > > 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). During the testing phase, I've created a batch file that deletes the existing repository and creates and initializes it all over again. This gives me repeatability in testing, and it also gives a batch file to initialize the final repository when I'm ready to create the production repository. But note that this sequence of instructions gets executed only once per project, and only when the repository is being created. > 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.) Could you please tell me what those approaches are? I'd really like to know. > - 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 Thank you, thank you. This is information I needed. I'll try it tomorrow. > - 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 > ] OK, I was following the documentation (cvs.pdf) and an example that I found on the internet. There doesn't seem to be a "c" option mentioned in the documentation. What does it mean? I used: > *.doc -k 'b' -m 'COPY' > *.dot -k 'b' -m 'COPY' > ... etc. > * -m 'COPY' I was hoping that this would make all the specified files (*.doc, *.dot, etc.) binary, and would enforce exclusive edits for all other files, but all it did was make every file an Ascii file. > 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. I just became aware of this when I was in the middle of things. I'm going to try this next. In the meantime, I continued using trigger files because I wanted to understand how they worked. > 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. That's the way it works in VSS, and I expect it to work the same way here. Sincerely, John John J. Xenakis Xenakis Consulting Services Inc. 44 Dinsmore Ave #304 Framingham, MA 01702 Phone: 508-875-4266 E-mail: john at jxenakis.com http://www.jxenakis.com a.e