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 think I've gotten everything working on a prototype basis, including > the shadow repository, but I'd like to share what I've done and ask if > I've followed "best practices." When talking about cvs, it's probably best to use the cvs-common terminology. The repository is where the "*,v" files are. This should be accessed only by the cvs server, and not be a share. (There's no reason for this to be a share.) Everything else (that you created with a "cvs checkout" command and that contains the files in a useful form) is a sandbox. It seems that the "shadow repository" you are talking about is actually a sandbox (and not a shadow repository; which could be understood as a mirror of the repository files). > - User Interface > > There will be about 10-20 users working collaboratively on about 200 > Microsoft Word DOC files. [...] I've tested both TortoiseCVS and > WinCvs, and find that they both work very nicely, individually and > together. Note that it is very important with binary files like Word files that the user works always on the latest revision (because they can't be easily merged). Tortoise ensures this by automatically running an update before the edit on binary files. With other methods (command line or Wincvs), the user has to make sure of this. > - 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). [...] > > cvs co Project > cd Project > cvs watch on > cvs commit > cvs unedit I'm using this mechanism for binary files only. A watch on the repository (once set) takes care of this; no further special commands in individual sandboxes are necessary. Not sure this would work with text files, though. The above doesn't seem to enforce this. > - Using COMMITINFO triggers > > There's one more idea I'm thinking of trying. I've found out that > "%s" is OK with commitinfo triggers, so the algorithm would be this: I'm using loginfo (with Bo's CVSMailer). It seems to get called once per directory in a commit. It should be possible to trigger the checkout commands here. (BTW, you don't have to distinguish between checkout and update. You can use checkout, even if the file/directory already exists. That makes the logic a bit quicker.) > - Shadow repository on a share > > Can anyone suggest a "best practices" way of doing this? I'm thinking > of a separate userid and password just for the shadow repository, so > that if it's discovered, the exposure will be limited to just the shadow > repository. It seems you are talking about a sandbox here, not really a repository. I'd say use a user that is being used only for this purpose, and this user needs only read rights (no writing) to the whole repository. I never had a sandbox on a share, so I can't comment on this aspect. It seems to be possible, though, because Tortoise has an option to enable it. Gerhard