[cvsnt] Re: Best practices for shadow sandbox

[Oliver Giesen]

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