On Fri, 28 Jan 2005 13:39:08 -0700, Gary Thornock <[EMAIL PROTECTED]> wrote: > I'll readily admit, this is a weakness of CVS, and it might > be enough to make CVS unsuitable for the particular work that > was asked about in this instance. That weakness doesn't, in > my opinion, make up for the performance problems, Berkeley DB > corruption problems, ridiculously huge disk usage on both the > server and the client (yes, I know it was an intentional design > decision), lack of tagging and branching (yes, I know about svn > copy), global instead of per-file revision numbers (again, yes, > I know it was intentional), and a host of other irritations with > Subversion.
All of these intentional design decisions were truly _intentional_ and solve some of the weaknesses in CVS. The sad fact is that CVS does not allow you to roll back to where you were a week ago unless you haven't changed anything about the directory structure (including file names). The ability to roll back reliably ought to be a base requirement of any VCS and most of those "irritations" you mention are what make it possible. What good are tags if they don't actually take you back (reliably) to where you were then? As for tagging and branching I really have to object. If you think Subversion doesn't support branching you've missed how elegant their solution is. Tagging, on the other hand, is sort of irrelevant since every revision is a tag. If they did support some sort of non-copy tagging it would only be a way to make an alias for a tree revision. I think they should support that, and it would be really easy to add since it's just an alias. And what else were you going to do with the 80GB HDD? I'll bet you a nickel you've got at least 10GB free still. The advantage gained by keeping a pristine copy local is a small price to pay for a little disk space lost. I can diff my changes against my last update while I'm on the bus (with no extra work), can you? -------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
