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: >> > 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 > > 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. OK, but the unedit is still pointless without an edit preceding it. Also I was assuming that there were actually happening some modifications at some point between the checkout and the commit. Otherwise the commit is equally pointless. >> 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. I've listed them below and you already replied to them. > 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? AFAIK it's only supported by CVSNT so you're unlikely to find it mentioned in any general CVS documentation. Including "c" with a file type's flags in cvswrappers will result in the following behaviour: 1. Adding or importing a file of that type without explicitly specifying any other -k options will add it with the specified flag(s). (Duh) 2. Checking out such a file will always behave as if you specified the global -r option (e.g. cvs -r co SomeFile.txt), i.e. the file will be read-only after checkout. This is intended to force users to use the cvs edit command to make the file read-write before making any modifications. 3. Editing such a file will always behave as if you specified the -c option (e.g. cvs edit -c SomeFile - aka "Reserved Edit"). This means that the Edit will only succeed if nobody else already has that file edited. 4. Committing such a file will always behave as if you specified the -c option (e.g. cvs ci -c SomeFile). This means that the Commit will only succeed if you are a valid editor of the file (see 3) > I used: > >> *.doc -k 'b' -m 'COPY' >> *.dot -k 'b' -m 'COPY' >> ... etc. >> * -m 'COPY' I don't really know whether CVSNT still supports the -m directives in cvswrappers. I think I remember Tony thinking aloud about deprecating them. In any case, -kb would imply COPY behaviour so that is superfluous. > 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. It shouldn't have. Could well be because CVSNT no longer knows how to handle the -m directive and as a result simply ignored the whole line. And neither -kb nor -m COPY have (/would have had) any effect on the behaviour of edit operations. That's what -kc and -kx are for. Hope this helps. -- Oliver ---- ------------------ ICQ: 18777742 (http://wwp.icq.com/18777742) MSN: ogiesen at hotmail.com Y! : ogiesen