[Xcb] SCMS for XCB?

Trevor Woerner xcb506 at vtnet.ca
Sun Jul 31 04:30:31 EST 2005


On Saturday 30 July 2005 13:34, Barton C Massey wrote:
> I would
> suggest we just move to svn---but do we really want to do a 
> second move when someone finally builds us a decent open
> SCMS with distributed changeset support?

Perhaps it's unrealistic to think that we can find one SCM tool and 
never have to move away from it for the rest of our lives? Maybe 
upgrading is inevitable. Wasn't there a time when CVS was the cat's 
meow? :-)

Because of my inability to make up my mind (and because I can't find the 
perfect solution) my current "latest" computer at home is a PIII-733 
(apologies to those who would drool over such a machine). Surely if I 
walked into any computer store today with a blind-fold on an bought the 
first machine I knocked off the shelf it would be a better decision 
than the decision to wait for the perfect machine?

> Also, is a 
> reasonable ASCII repository format a requirement?

Subversion has had support for both ASCII (fsfs) and binary (Berkley-db) 
repository formats for a while. Whoever sets up the repository has 
always had a choice, although db has been the default. With the latest 
release of subversion, 1.2.0, fsfs (i.e. ASCII) is now the default.

> What do *you* all think?

In brief, I think we should move to subversion until something better 
comes along. The learning curve is virtually non-existant: the only 
thing you have to learn is to type "svn <something>" instead of "cvs 
<something>". All the commands and behaviours are virtually the same.

But as a bonus, all the current frustrations with CVS go away. I'd be 
happy to get into a lot more elaborate detail but I'll spare you the 
gory stuff. Suffice it to say:

1) subversion supports atomic commits, checkouts, etc. If a checkout 
takes an hour to perform over a slow network, I can be assured that 
nobody's commits halfway through are going to mess up my transaction.
2) subversion can store things like file permissions and symlinks
3) you can commit a diff that consists of moving, renaming, and deleting 
files and directories
4) you can attach arbitrary properties (tag:value pairs) to any item 
(e.g. this could be useful for things like "signed off by" tags)
5) subversion is quite smart about network usage; for example, it will 
store the latest version locally so if you want to perform a diff with 
the latest version no network activity is required

I guess what I'm trying to say is that I believe all decisions will be 
wrong from someone's point of view. But in the mean time why not move 
to something that will require almost no learning curve and provide 
relief from our most annoying issues?


More information about the xcb mailing list