[cvsnt] Re: Best practices for shadow repository

[Oliver Giesen]

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)