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 very much appreciate your commenting on the "best practices" stuff. > I can't find anything on the internet on best practices for CVS. Did you run a Google search on "best practices" (quoted) and cvs? It comes up with quite a number of links that look like they have something to say. Maybe no "best practices bible" around, but that's probably because the environments (development, team, administration, IT) are so different. > 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. It's not as "round" as some commercial solutions. But that's not exactly the same as "shoddy" (in my book, at least :) > 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. IMO you need to find out what exactly you need, and this depends a lot on the specific environment. Then you have to set up a set of "best practices" using the available tools. For some environments, cvs(nt) is probably not a good match, and other choices may be easier to implement. But it's not a question of any of the tools "addressing" a fixed set of best practices -- the question is how you can address your requirements with the available tools. The cvsnt and the cvs manual are good starting points for this. Note also that TortoiseCVS and WinCvs are not the only client-side tools that are available. There are a number of other clients, some shells around cvs.exe, others with their own client implementation. There are also tools that implement the Microsoft SourceSafe SCC interface (one that I'm using is from PushOK Software). > One thing that Microsoft Visual SourceSafe does very well is to enforce > best practices ... Whether what VSS enforces or encourages are really "best" practices is really a matter of opinion (and don't be surprised if most here don't share your opinion about this being "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. CVS has been designed by developers for developers, basically. There's not really the "naive user" in this environment. It has grown since then, and some of the client tools, together with a good set of rules (or "best practices") and a capable support, can go quite a ways to make this work for the naive user. I use it here around the house with "naive users" quite successfully, using shell scripts. > 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. It's always difficult to mimic the working of one tool with another one. You often end up with something that's not as good as the one it's mimicking, but underutilizing the added benefits of the used tool (because they are not part of what is supposed to be mimicked). >> 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. I usually tell the less sophisticated users to use Tortoise for general use. >> I'm using this mechanism [watch] 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. You could look at what it means when a file is marked as "binary". It basically means two things: 1- End-Of-Line characters get not translated between different client operating systems. For text files, you get the correct line terminations, no matter whether you check out the files on a Unix type or Windows operating system. 2- Files don't get merged by cvs. (That's where the usual requirement comes from to work only on the last revision.) If you want to enforce exclusive edits, one possibility is to add these files as binary -- if you can live with the above two consequences. This has the advantage to be compatible with pretty much all cvs client tools, as all of them recognize binary files. You can set up a server-side cvswrapper file that contains entries for the various file types and forces them as binary files. AFAIK you can also specify the -kx option there. The possible disadvantage with this is that some of the client tools may not be aware of this option. For example, I don't know whether Tortoise does the automatic update-before-edit on -kx files (like it does on -kb files). > 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. Yes, you can. The "cvs ls" command gives you the basics, and there are a number of client-side tools that provide you with a "server side" GUI view of the repository. The cvsnt Workspace Viewer is one (it comes with a very limited functionality in the open source version, but I'm told that the paid version can do more). Other client tools, like for example SmartCVS, implement something similar. Gerhard