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 Gerhard, Thank you very much for your response. It was greatly appreciated, and I'll try to keep the terminology straight. I very much appreciate your commenting on the "best practices" stuff. I can't find anything on the internet on best practices for CVS. CVSNT is an incredibly good product, and very sophisticated, but if it's configured poorly, then not only does the consultant look non-professional, but the product appears to be buggy and shoddy. So "best practices" information is very important. In fact, one of the people at my client was opposed to using CVSNT, arguing that it was a "shoddy product." I suggested that his previous experience had been with a poorly configured CVSNT setup, and I said that I would set it up according to best practices. I hope I can keep my promise. I think that what may have happened is that "best practices" is falling between the cracks -- it can't be completely addressed by any one of the products CVSNT or TortoiseCVS or WinCvs, and so no one really addresses it. One thing that Microsoft Visual SourceSafe does very well is to enforce best practices -- a clean user interface implementing the "principle of least astonishment," so that the menus are laid out so that the naive user will do the right thing. It's important to find a way to get CVSNT to work as well in this regard as SourceSafe, but it's sure hard to find information. > > - 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. Thanks for pointing this out, and I guess this means that it's dangerous to encourage users to use WinCvs unless they're sophisticated enough to deal with this issue. > > - 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. Yes, I've verified that this is correct. As far as I can tell, cvsnt will enforce exclusive edits on binary files, but the only way you can do that with text files is to use the "-x" option with "cvs edit", and as far as I can tell there's no way to get TortoiseCVS to use the "-x" option. It's very discouraging that this option isn't available. Since there are few text files in this project, I'll try to convince the client to use the CVS concurrent editing model, even though it'll be very startling to some of the users. Otherwise, perhaps there's a way to enforce exclusive locks on text files by means of a "precommand" trigger. ------- There's one more serious usability problem that perhaps you could comment on -- the "client view" rather than the "server view." This seems like a relatively small thing, but it appears to have major consequences. In Microsoft Visual SourceSafe you can browse the entire directory structure on the server. Once you've set up your working directory (sandbox directory), you can selectively "get" or "checkout" one, two three files, or an entire sub-directory, or the entire project. But on CVSNT you can't do any of that stuff, as far as I can tell. A new person who's going to be working on one single file can't even get started without getting the entire project onto his hard disk. If the project is a large one (which my client's project will be), this is a huge burden to place on someone who's just going to be working on one file, or a small group of files. Am I missing something here? This must be a problem that every installation faces. Is there a way for someone getting started on an existing project to be more flexible than checking out the entire module? Is there a way to use the "shadow sandbox" as part of a solution? As before, I appreciate any comments you or anyone else can help with. 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.a