Subversion Hits Alpha

C. Michael Pilato writes: "This overheard while eavesdropping on announce@subversion.tigris.org: Gentle coders, The ever-growing cadre of Subversion developers is proud to announce the release of Subversion 'Alpha' (0.14.0). Since we became self-hosting eleven months ago, we've gone through ten milestones. This milestone, however, is the one we've always been working towards; it's a freeze on major features for our 1.0 release. From here out, it's mostly bug-fixing. We hope this announcement will lead to more widespread testing; we welcome people to try Subversion and report their experiences on our development list and issue tracker." Subversion, a source control system akin to CVS, has been in the works for a couple of years now.

Comments

Why?

[Anonymous Coward]

Just use some of the perfectly good source control programs out there. Visual Basic Source-Safe comes to mind.

Re:Why?

[Peyna]

Isn't Source-Safe expensive?

Re:Why?

[LordStrange]

Isn't Source-Safe expensive?

Yes. Insanely expensive. It is pretty good but not really close to being worth $500 per seat (when purchased separately from Visual Studio).

Re:Why?

[Junta]

If by 'pretty good' you mean 'total piece of shit', I agree. Most of the Visual Studio suite is pretty decent, but Source Safe comes off exactly as what it is, a software package bought out by MS for the express purpose of saying Visual Studio has SCM, and then doing next to nothing with it to make it work better. As an admin in a shop of people begging to leave Source Safe for something like Rational, or even CVS, I know how it is... Subversion may offer the core needed to build a replacement that keeps both developers and the businessmen happy...

Re:Why?

[Storm Damage]

Only $500/seat? Good lord how I wish our versioning software was that cheap. Right now I'm writing a Purchase Request for 4 more Rational ClearCase licenses...

When the license + 1 year support for each is all added up, we'll be cutting a check to the tune of about $16,000

I've asked the CM people before why we're not using something cheap (free) like CVS (as the sysadmin, I don't get to make the decisions, I just get to make it work once the stuff is purchased), and they casually said "Hell, I don't know, that's just what we're stuck with."

I guess "Hell, I don't know, that's just what we're stuck with" is an appropriate attitude when you've got oodles and oodles of taxpayer dollars to spend...

I know, I know. I'm going to hell.

Re:Why?

[noselasd]

I agree that there are plenty of good source control programs. SourceSafe is NOT one of them, I have to use it every now and then and know The idea is that you control the system, not the other way around. Besides, it isnt free, and there some people that would like a free source control system - imagine that.
Good source control systems includes Bitkeeper and ClearCase. Neither of those are free/opensource.

Re:Why?

[ChaosDiscordSimple]

I suspect that the anonymous coward is joking, but please, if you care about your source code at all, do not use Visual SourceSafe. Visual SourceSafe is awful software that plagued my existance for five years. If you are using Visual SourceSafe, or are considering it, please see this page on Visual SourceSafe's faults.

Re:Why?

[Dragonmaster Lou]

Ugh. No offense, but you must be some kind of masochist if you like ClearCase. I honestly do prefer CVS to it (even though it does have a few nice features) just because it's such a pain in the ass to use and install.

Re:Why?

[Dragonmaster Lou]

I wouldn't call ClearCase "good." Better than SourceSafe from what I heard, but it is a pain in the ass in many ways. Yes, it scales, and yes, it gets the job done very nicely, but I'm not a big fan of *how* it gets the job done.

In 20 words or less.

[Anonymous Coward]

Tell me what has Subversion got that CVS hasn't? (No this is not a flame, I'd like to know).

Re:In 20 words or less.

[Westley]

Surely the easiest way of finding out is to visit the website. From the front page:

Directories, renames and file meta-data are versioned.

Commits are truly atomic.

Apache as network server, WebDAV/DeltaV for protocol

Branching and tagging are cheap (constant time) operations.

Natively client/server, layered library design.

Client/server protocol sends diffs in both directions.

Costs are proportional to change size, not data size.

Efficient handling of binary files.

Parseable output.

For more details, see the website.

Jon

Re:In 20 words or less.

[Fweeky]

Versioning of filenames (and other metadata) so you can svn mv something, cheap branching/tagging, binary diffs, and atomic commits.

Re:In 20 words or less.

[ebuck]

It's been awhile since I looked at it, but as I recall:

In 20 words or less:

Subversion is CVS on steroids without being tied down to the history of CVS.

And some of the reasons why are:

Subversion handles directories.
CVS does not.
Subversion handles file permissions.
CVS does not.
Subversion makes atomic commits (and rolls back prior to the commit if necessary).
CVS cannot, it will stop at the last file processed (and you have to clean it up by hand).
Subversion uses HTTP/WebDAV (both reliable protocols).
CVS uses it's own protocols which might be less reliable.
Subversion performs more operations in constant time.
CVS uses more time for the same operations although it is not necessary.
Subversion is naitvely client-server.
CVS had the client-server added on after the core code was developed creating some odd aspects of operation.
Subversion transmits deltas, so costs are porportional to change size.
CVS changes are (I believe, not know) proportional to project or file size.

--- Fabrication is the stuff filling the holes of memory.

Re:In 20 words or less.

[Eccles]

Tell me what has Subversion got that CVS hasn't? (No this is not a flame, I'd like to know).

To go into a little more detail:
The key difference (although there are many) is that you check in (or commit, or submit, or) a change, not a file. Thus all related changes are bound together. It makes it a lot easier to understand how the code is changing, the code should compile after each change (and if it doesn't, you can figure out whose fault it is), and you can get an older version based on its commit number. You can also do things like tying the commits to a verification system, and that system can report build failures, tag versions as being buildable, passing regression tests, etc.

Perforce (among others) is organized in this fashion, and it really makes a huge difference if you're working with lots of developers.

Re:In 20 words or less.

[ebuck]

One odd aspect comes to mind directly, modifications to CVS code must be made in two places to have effect.

Modify it once to support the old "there's no network" calls. Modify it again to support the added on "network enabling code".

For most users this is not a visible issue, that is until:

1. You issue a command via network and it doesn't act like a command when you're in the box.
2. You want to know why #1 happens.

Yes, you can argue that having a web server is extra overhead, but that burden is being supported by people who worry about web servers full time, not by those who worry about source code control. And if you're not using a network, why the extra overhead of CVS? RCS would remove the network overhead entirely.

Re:In 20 words or less.

[ftobin]

Subversion uses HTTP/WebDAV (both reliable protocols). CVS uses it's own protocols which might be less reliable.

CVS uses ssh which is much more reliable and secure than yet-another-protocol-over-HTTP.

Re:In 20 words or less.

[slamb]

CVS uses ssh which is much more reliable and secure than yet-another-protocol-over-HTTP.

CVS uses [kgnp]server (Kerberos, GSSAPI, NTLM, Password) as its communication protocol. It's not even encrypted.

The cvs-over-[rs]sh thing is a kludge, an extension of the local repository access. It requires each person have a Unix shell account with write access to the repository. You can't do much security-wise with that. Since CVS stores each file independently, you can at least say they don't have access to a module but you can't say they don't have access to a certain branch. And you certainly can't say something like "they can't delete/modify existing revisions".

HTTP/WebDAV/DeltaV is nice for a few reasons:

• the protocols were already made. HTTP, TLS, WebDAV, and DeltaV all existed beforehand. The authentication and stuff were settled. It saves work designing protocols.
• Support of existing software. You can mount a Subversion repository read-only with no special software in most operating systems. ("Web folders" under Win2K for example. Try it. http://svn.collab.net/svn/repos/trunk) Eventually, even write access with automatic versioning. (Which means the log messages will be pretty worthless, but it has some of the advantages of revision control and is completely transparent.) DeltaV-supporting software will probably start to come out pretty soon as well.
• Existing code. Apache has a pretty solid server architecture. It divvies up the requests, handles TLS, does authentication, logging, etc. mod_dav was already written as well. mod_dav_svn is a pretty small part of the whole.

Re:In 20 words or less.

[ftobin]

CVS uses [kgnp]server (Kerberos, GSSAPI, NTLM, Password) as its communication protocol. It's not even encrypted.

Noone in their right minds uses this.

The cvs-over-[rs]sh thing is a kludge, an extension of the local repository access.

It's a 'kludge' that works extremely well, and fits well into the unix philosophy.

It requires each person have a Unix shell account with write access to the repository. You can't do much security-wise with that.

False. It requires that they have an account on the system, not one necessarily that allows you to execute a shell (just like SourceForge has it set up).

Since CVS stores each file independently, you can at least say they don't have access to a module but you can't say they don't have access to a certain branch. And you certainly can't say something like "they can't delete/modify existing revisions".

True. But this has little to do with the transport protocol.

Re:In 20 words or less.

[BlowCat]

CVS uses [kgnp]server (Kerberos, GSSAPI, NTLM, Password) as its communication protocol. It's not even encrypted.

Oh, yes, very "informative".

From cvs.info (Direct connection with GSSAPI):

The data transmitted is _not_ encrypted by default. Encryption support must be compiled into both the client and the server; use the `--enable-encrypt' configure option to turn it on. You must then use the `-x' global option to request encryption.

Re:In 20 words or less.

[aled]

I It's a 'kludge' that works extremely well, and fits well into the unix philosophy.

I prefer something that works extremely well and fits well into the internet / interoperability / multiplatform philosophy.

Re:In 20 words or less.

[slamb]

> > CVS uses [kgnp]server (Kerberos, GSSAPI, NTLM, Password) as its communication protocol. It's not even encrypted.

> Noone in their right minds uses this.

Right, no one uses its authentication for anything important. CVS doesn't have a decent protocol. For extra annoyance, they do use it for anonymous stuff, since it is not good to have a Unix account for anonymous people. So you need two different ways of accessing CVS.

> > The cvs-over-[rs]sh thing is a kludge, an extension of the local repository access.

> It's a 'kludge' that works extremely well, and fits well into the unix philosophy.

No, it does not work well. There's not a lot of Java code available to talk ssh, for example. It's not good for cross-platform stuff.

Also, ssh handshakes are time-consuming. This is important because cvs reconnects for each operation. In contrast, HTTP has well-defined and well-known standards for keepalive and pipelining.

> > It requires each person have a Unix shell account with write access to the repository. You can't do much security-wise with that.

> False. It requires that they have an account on the system, not one necessarily that allows you to execute a shell (just like SourceForge has it set up).

I'm afraid you have me at a disadvantage - I've not seen SourceForge's setup. I'm not a committer on any projects there. However, ssh requires a shell account - it might be a restricted shell of some sort, but they need a shell.

Also, the manual certainly has no better way. If you are able to do so, please patch it. I quote:

It is possible to grant read-only repository access to people using the password-authenticated server (*note Password authenticated::). (The other access methods do not have explicit support for read-only users because those methods all assume login access to the repository machine anyway, and therefore the user can do whatever local file permissions allow her to do.)

There are a lot of things not possible to do with Unix file permissions. Saying things can be added but not modified. (You can have setgid directories, but not setuid ones.) One group that can read/write, one that can read, everyone else who can do nothing. Permissions within the files (short of splitting them into more files, which makes Subversion's ACID semantics difficult) . All of these things are possible with Subversion - you just write a Perl script that inspects the transaction and allows or denies it. Please take a look at commit-access-control.pl for an example.

> True. But this has little to do with the transport protocol.

You need a smart server to accomplish this. Subversion's :ext: method of remote access (rerunning the command on the other machine through [rs]sh) doesn't qualify. Arch's modify-via-ftp doesn't either. Those can't ever do anything but the Unix file permisssion way, but with a server between it can decide what is allowed or denied.

You notably didn't quote/comment on my points about why HTTP/WebDAV/DeltaV was a good choice. They clearly needed a protocol of some sort. I think using the existing standards was a good choice. Why would something else be better? Why would you not use HTTP? You said:

> CVS uses ssh which is much more reliable and secure than yet-another-protocol-over-HTTP.

Do you have anything to back that up? How is HTTP/TLS/WebDAV/DeltaV unreliable or insecure?

If you're that dead set against that protocol, write a new one. It already has the abstraction - both ra_local and ra_dav are supported. Write a new ra_XXX if you so desire. And a new server to replace mod_dav_svn. Of course, no one will use it - the DAV stuff works well. But maybe you'd feel better.

Re:In 20 words or less.

[ftobin]

There are a lot of things not possible to do with Unix file permissions.

You assume a basic unix filesystem, not something like AFS, which has rich, powerful (though not sub-file) ACL support.

However, ssh requires a shell account - it might be a restricted shell of some sort, but they need a shell.

SourceForge only lets you execute cvs when you login (that is, you cannot execute any other program, including any shell). Furthermore, you really don't need line in /etc/passwd, if that is your concept of a 'shell account'. SourceForge uses an LDAP server, I think, for accounts. So, given the abscence of a line in /etc/passwd, and only the ability to execute 'cvs', I don't quite see how this qualifies as a 'shell account'

You notably didn't quote/comment on my points about why HTTP/WebDAV/DeltaV was a good choice.

I did not comment because I had nothing to argue against in what you said, they were all quite true statements. But the benefits you stated has no value to me.

How is HTTP/TLS/WebDAV/DeltaV unreliable or insecure?

The cryptography for ssh is much more secure than the examples you've give. The authentication means are more powerful, and there is agent-forwarding, both extremely important.

And a new server to replace mod_dav_svn.

I highly dislike systems writing servers where none is needed (ala CVS with [rs]sh; ssh handles the network).

Re:In 20 words or less.

[slamb]

> You assume a basic unix filesystem, not something like AFS, which has rich, powerful (though not sub-file) ACL support.

Right. I assume what's commonly available. And AFS still can't do the right thing. If you've noticed, Subversion goes to the other extreme in terms of numbers of files - everything's in a single Berkeley DB. This allows them to have nice ACID semantics. So granting access in this way would be all-or-none - awful instead of merely bad.

> Furthermore, you really don't need line in /etc/passwd, if that is your concept of a 'shell account'.

That definition is wrong. On www.slamb.org, user slamb has a UID and a login shell, but not a line in /etc/passwd. The NSS method is completely irrelevant.

If you do a "finger cvsonlyuser" on SourceForge, I'm sure it will say "Shell: /cvsonly/shell" or something. When given "-c cvs" arguments, it must invoke cvs. That program is, by definition, a shell. You may be correct that this is not a huge security flaw, but my terminology is right. And also the cvs manual says nothing of how to restrict stuff in this way - again, it should have the best security practices.

> > How is HTTP/TLS/WebDAV/DeltaV unreliable or insecure?

> The cryptography for ssh is much more secure than the examples you've give. The authentication means are more powerful, and there is agent-forwarding, both extremely important.

The only example I gave was the access control script - that's authorization. I did not discuss how HTTP authentication & TLS works. Authorization != authentication.

There's nothing wrong with TLS's cryptography. It doesn't do agent forwarding, but it doesn't need to: you aren't forwarding the agent to the Subversion repository. It would be possible to do agent forwarding to the client to get its key. No one's done it (no one's even implemented TLS certificates - that's issue #650, I'm looking forward to it) but it's possible.

> I highly dislike systems writing servers where none is needed (ala CVS with [rs]sh; ssh handles the network).

It's important to have a smart server to have flexible authorization. You simply can't do it otherwise.

This is very similar to any RDBMS. They provide fine-grained security and ACID semantics. They need servers to do it. No one questions them.

But again - if you want it done a different way, do it. Write a new ra_xxx and an executable that, when forked from ssh, communicates with the client. (Call it something other than a server if you like.) I actually see a partially written ra_pipe - that might be what you want, not sure.

Re:In 20 words or less.

[ftobin]

If you do a "finger cvsonlyuser" on SourceForge, I'm sure it will say "Shell: /cvsonly/shell" or something. When given "-c cvs" arguments, it must invoke cvs.

You're confused as to how this is implemented. ssh itself allows you to restrict the command to ssh. From the sshd manpage:

command="command"

Specifies that the command is executed whenever this key is used for authentication. The command supplied by the user (if any) is
ignored.

There's nothing wrong with TLS's cryptography. It doesn't do agent forwarding, but it doesn't need to: you aren't forwarding the agent to the Subversion repository.

I'm well aware that I'm not forwarding the agent to the repository, but I am forwarding the agent from my base machine to where I do my work, and from there I authenticate to the repository.

Actually, I can easily forsee needs to forward the agent to the repository, if the repository needs to authenticate to something like the filesystem (ala AFS).

It's important to have a smart server to have flexible authorization. You simply can't do it otherwise.

I don't diagree with that statement. However, the 'smart server' doesn't need to know anything about the network, just talk over a unix domain socket.

This is very similar to any RDBMS. They provide fine-grained security and ACID semantics. They need servers to do it. No one questions them.

The need for database systems to talk over a network I do question.

Write a new ra_xxx and an executable that, when forked from ssh, communicates with the client. (Call it something other than a server if you like.) I actually see a partially written ra_pipe - that might be what you want, not sure.

If cvs's ever begins to actually be a worry for me, and I consider a different version-control system, I might look into it. But that would likely mean having to work with WebDAV, which is another argument in its own right.

Re:In 20 words or less.

[slamb]

> I'm well aware that I'm not forwarding the agent to the repository, but I am forwarding the agent from my base machine to where I do my work, and from there I authenticate to the repository.

Right, so the Subversion protocol does not need special support for it.

> Actually, I can easily forsee needs to forward the agent to the repository, if the repository needs to authenticate to something like the filesystem (ala AFS).

Not necessary with mod_dav_svn - it uses standard Unix filesystem operations with its uid no matter how you authenticate to it.

For that matter, Berkeley DB doesn't work on NFS, so it probably doesn't on AFS either. Locking. Same as a RDBMS.

> However, the 'smart server' doesn't need to know anything about the network, just talk over a unix domain socket.

I suppose. But ssh+pipe means that:

• it must forks/exec for each connection. I've learned from moving to CGI to Servlets that forking really slows things down. (You'd expect Java stuff to be much slower, but that's not true.) IIRC, sshd forks two processes with privilege seperation. One of those execs your binary (even if it doesn't go through a shell).
• You require a Unix UID. I just don't like this idea. It's unnecessary.
• It doesn't have the interoperability of HTTP/WebDAV/DeltaV. Those work with a lot of software, and not just in the Unix world. So there's no getting rid of that stuff for me.

> > Write a new ra_xxx and an executable that, when forked from ssh, communicates with the client. (Call it something other than a server if you like.) I actually see a partially written ra_pipe - that might be what you want, not sure.

> If cvs's ever begins to actually be a worry for me, and I consider a different version-control system, I might look into it. But that would likely mean having to work with WebDAV, which is another argument in its own right.

Ehh? It would replace WebDAV.

Re:In 20 words or less.

[ftobin]

Right, so the Subversion protocol does not need special support for it.

Well, if it uses a different protocol, it will probably be hard to tie talking to the agent for authentication with the protocol Subversion would be using. In other words, while I could forward the agent to from point 1 to X-1, where X is Subversion, and not need to forward the agent from X-1 to X, and the protocol through 1 to X-1 and X-1 to X are different, it would be difficult to get these two protocols to 'talk'.

For that matter, Berkeley DB doesn't work on NFS, so it probably doesn't on AFS either. Locking. Same as a RDBMS.

Actually, I wouldn't be at all surprised if AFS supported locking, but I won't delve too deep here, since I'm not sure. But certainly don't rule it out.

The fork-exec cost is highly overrated in my book (assuming the code is already in memory), given copy-on-write.

You require a Unix UID. I just don't like this idea. It's unnecessary.

This is one drawback, yes, but lessed a great deal with NSS and the like. It's not the UID that is the problem (practially all systems have a user id of some sort), but more the tying of multiple authentication databases together isn't that great. I wouldn't be surprised the ssh people are working on making it good for authenticating more than unix accounts, though.

Ehh? It would replace WebDAV.

Oh, I was more referring to trying to replace the transport mechanism (HTTP(S)), not the communications layer (what is actually spoken across it).

Re:In 20 words or less.

[ebbe11]

so your saying basicly 1/10 the stuff that would go into cvs if the developers had a brain cell among them

They do. But they have decided that adding this fucntionality to CVS is not viable, so they're developing subversion instead.

Hint: Many of the subversion developers are also CVS maintainers.

Four words

[Anonymous Coward]

A way cooler name.

testing subversion/cvs...

[grey1]

Does anyone have a test set to try subversion (or cvs) out with, lying around at the back of a directory somewhere?

Seriously, though, how, other than using it for real, might one test subversion? And how would you recover from the bugs that will be in there without devoting your life to it for a few weeks?

Just wondering.
Graham

Re:testing subversion/cvs...

[Anonymous Coward]

they use RCS file text and diff files, so you can make a weekly backup of them (or more often. You do make backups, don't you?), and if something gets funky, you can extract the info from the ,v files.

Re:testing subversion/cvs...

[grey1]

yes of course I make backups but when testing something that's in alpha, if I'm testing it with real work, I either

a) hope nothing goes wrong (ROFL)
b) backup my personal source tree immediately before each subversion commit step

Because otherwise you can guarantee that when I want to roll back 2 or 3 steps to dig through an issue with my code, I'll hit a bug in subversion.

Now do you get what I was asking? And why?
Maybe next time I'll use a few more words...

Re:testing subversion/cvs...

[nthomas]

Seriously, though, how, other than using it for real, might one test subversion? And how would you recover from the bugs that will be in there without devoting your life to it for a few weeks?

You raise some serious concerns, let me try and alleviate those fears.

I've been using Subversion for a few months now (since revision 1210 or so), and let me to tell you, there is nothing that the dev team values more than the integrity of your data. Nothing. This means that once something has been comitted, it will never be lost.

Does this mean your data is guaranteed with an alpha-quality system? No. But let me tell you, in 6 months I've not seen it happen once. Oh sure, there have been a few times when the DB schema changed, and the format of the dumpfile (more on that in a bit) changed on you, but these things were discussed well in advance on the dev list and not only did you have plenty of opportunity to prep your data for the change, there were ways for you to convert your data after the fact.

If you are the sort of person that likes to tweak around with your data in the repository (if you come from a CVS background -- you have to be) and gets the heeby-jeebies from having your data stored in a non-accessible format, let me ask you this, do you worry about the fact that you have data stored in Oracle/Postgres/Sybase/MySQL? No? Then why worry about the Subversion repository at all?

Of course, the dev team has provided you with some nice backup tools, for example, the normal Unix cp command can be used to make hot-backups of your repostories, a very cool trick. In addition, there is an svnadmin command that has a "dump" feature that allows you to store your repository in a text file, if you worry about Subversion trashing your data, keep regular dumps of your repository.

Of course, all is not rosy. I would like to see a patchsets feature, and I really miss "cvs annotate" (but "svn blame" is scheduled to be added after the 1.0 release), and of course, the db has a tendency to lock up every once in a while (you can fix it easily with db_recover) but by and large, these are things I can live with.

After using this system for a while, I've come to one conclusion: it works. And it works better than CVS. Forget the years of bad habits you learned on CVS, once you start using Subversion, you will start to think about SCM systems in a whole new way. Try it out.

Re:testing subversion/cvs...

[my_furry_butt]

Something that might give you more confidence is that as subversion is self-hosting, much of what you would test on "real code" is being done every day by the subversion team, and has been for months. Branching, merging, rollbacks, etc would have to be pretty rock solid by now, otherwise the SVN team wouldn't be able to self-host effectively.

But extreme pessimism for the first couple of "checkout-edit-compile-test-release-commit" cycles wouldn't hurt either - just don't expect to be shocked at issues.

I think this alpha stage is more about getting a wider audience using SVN, and give feedback on usability, rather than stability and correctness. Things like how noisy is it, how informative, can a oft-repeated three-step process be reduced to two, or one (or none!) with a little thought for SVN's activites. Stuff that comes up when code is released into the wild.

Re:testing subversion/cvs...

[slamb]

Of course, the dev team has provided you with some nice backup tools, for example, the normal Unix cp command can be used to make hot-backups of your repostories, a very cool trick.

Please check out hot-backup.py. It doesn't do much more than cp, but it doesn't just do cp repository backupdir. It copies the logfiles last. That's important.

not just "akin to CVS"

[Emrys]

It would be more accurate to say subversion:CVS::mozilla:netscape4. Subversion is intended to replace CVS, and it's core team is made up many of the people that currently maintain CVS. CVS has really reached the end of its life cycle; its really showing its age, and it just doesn't make sense to extend it anymore. No, this is not a "CVS is dying" post, but anyone who has adminned it has been frustrated with it from time to time, and Subversion aims to remedy that. They're keeping what's good about CVS and replacing the bad with better things based on decades of experience with CVS and improvements in the SCM field in general.

This is intended to be a replacement for CVS. No less, and no more (for the "more", see some of the more experimental SCM stuff like Tom Lord's arch).

Re:why does subversion exist?

[Emrys]

As I noted elsewhere, "they" *are* CVS, for all practical purposes. CVS is very old and showing its age and it's time for a rewrite. Updating has reached the end of where it can be useful, considering even CVS's networking layer was added as an afterthought/extension. Subversion is intended to supplant CVS.

Re:why does subversion exist?

[rtaylor]

The parent is almost a troll. If you look up who maintains CVS and who maintains subversion you'll find alot of the same people.

After a decade (has CVS been around longer?) some things just need to be restarted from scratch as every hack possible on the base has already been tried.

In the case of CVS, it's the storage format that is causing the largest problems -- and the reason for the term 'repo-copy' which is one of the most annoying things I can think of (repo-copy then check out an old version -- look, duplicated stuff!).

Thanks

[wichtolosaurus]

Currently working on a project completely relying on ClearCase(tm) configuration management, I am glad if anyone in the world hacks just a single line of code to improve the way we work with source control.

Re:Thanks

[mccalli]

Currently working on a project completely relying on ClearCase(tm) configuration management...

Be interested to hear what problems you're having. I used ClearCase in one of my jobs, and thought it was really rather good.

Cheers,
Ian

Re:Thanks

[renehollan]

What so bad about ClearCase? Well, yeah, the learning curve is steep, and licenses are expensive, and it is not free, but I've always found it to be a powerful tool (albeit easily abused) for advanced source code control, particularly when dealing with multiple branches/forks of a common code base.

Re:Thanks

[wichtolosaurus]

ClearCase(tm) is a pretty neat tool, no doubt.
Working on a medium to large project with it is a good choice.
But if you're out to get a huge project going, it's getting complicated. I'm talking about multi-site development. You just have to take so much attention, it will eat away a pretty large amount of time.
Not to mention the terror an unexperienced or badly trained engineer can cause.

Re:Thanks

[mccalli]

I'm talking about multi-site development.

Ah yes, I remember now. We too had to use it for multi-site development, and the speed was awful. So we got into some sort of remote syncing, and that turned into a nightmare too...

Yes. Now I recognise what you mean.

Cheers,
Ian

Re:Thanks

[Luyseyal]

I haven't used ClearCase, but I'm wondering if something like arch or BitKeeper with native support for distributed trees wouldn't help some of these central-server merging problems?

curious,
-l

way to go

[TTimo]

Way to go to the subversion guys
faster, better overall design, extendable, seamless integration with apache .. still gotta give it a few months to get finalized, but it's looking really good.

while we're at it, let's burn our Makefiles too

[soundsop]

While we're considering throwing away CVS, let's also throw out make. Check out Scons, a replacement for make. I have been using it for a few months on small projects and it's shaping up to be a really great tool.

Burn your Makefiles!

Re:while we're at it, let's burn our Makefiles too

[Anonymous Coward]

Also, check out jam. It's by the same people that brought you perforce.

Re:while we're at it, let's burn our Makefiles too

[smagoun]

...and there's always ant, from the folks over at jakarta.apache.org. It's aimed at java development, but can be used with other languages as well.

Ant has some pretty cool features (and a few misfeatures, sadly), but it's really caught on in Java-land.

Re:while we're at it, let's burn our Makefiles too

[e2d2]

Nant has also caught on in the c# world. It's basically a .net port of ant.

We are moving our visual studio build to Nant because it works with our Nunit tests and can do everything we need automatically. We have used both nmake (make) and VS to accomplish builds in the past but have had to overcome a few difficulties in large builds that hopefully this will solve. We'll see but using ant in the past for my java projects I am hopeful. Using nmake simply was to error prone on large builds, we don't like finding that our build failed because of whitespace problems, and VS was simply to unreliable for us (your own results may vary). We still use vs.net to build our custom installer, but we call it from the cmd line using Nant.

Tying the whole process in to a source control app like subversion or cvs (which we currently use) would benefit us. Hopefully someone will write a .Net cruise control or it' equal for the .Net platform. That would allow the build process to get the latest files from our repository for the build.

Re:while we're at it, let's burn our Makefiles too

[iabervon]

I never figured out a way to get ant to reliably compile a Java project correctly. It uses the javac dependancy engine, which is specified in a broken way (the rules in the specification don't actually mean that compiling the classes it finds as needing recompilation is the same as compiling from scratch).

After using ant for a while at my work, we decided that it was the most common cause of people checking in broken code (which hadn't caused a problem for the author) and incorrect builds, and switched to make (with a python script to find java dependancies correctly).

The other problem with ant was (at the time, at least), there was no way to avoid running a program because it could be determined that it was unnecessary. This made trying to use EJB with a container that required an EJB compiler practically impossible, because we had a 20 minute build cycle, even when the ejbc step wasn't necessary.

Re:while we're at it, let's burn our Makefiles too

[TTimo]

cons and scons are awesome tools. incredibly powerful and effortless compared to gnu make.

now that I have switched a number of my projects to cons/scons and used the tools for a few months, I don't see myself writing a makefile ever again

Re:while we're at it, let's burn our Makefiles too

[iabervon]

Make is actually quite nice if you use a little trick: have only one Makefile. Have that Makefile include a file from each directory that contains variable definitions. That way, you separate the code from the data, meaning that you don't need to automatically generate the Makefiles (since you don't change them for each project and directory), so the Makefiles can be readable.

You can also do some really interesting things with conditionals and what amounts to iterative includes. I have a set of Makefiles totalling 315 lines which will accurately do exactly the steps needed to rebuild a program if any source file changes, regardless of which directory the file is in, and can be run from any directory in the tree. If nothing has changed, make says nothing except "'target' is up to date". It wasn't terribly hard to do.

Re:while we're at it, let's burn our Makefiles too

[e2d2]

Nant doesn't favor one language, I just happen to use mainly c#. You could easily modify either ant or nant to build projects in other languages. Actually Nant has a task built in to compile using the VB.net and C++ compiler along with various other tasks just like make. Our builds include c++, c#, MS help files, and an MS installer.

Make is fine, but like I said we are searching for something a little more friendly.

Re:while we're at it, let's burn our Makefiles too

[obsidian head]

Hell yeah! Javac is so broken, and for being so unoptimized its not even a great reference implementation.

Re:while we're at it, let's burn our Makefiles too

[iabervon]

I have it at http://iabervon.org/~barkalow/make.tar.gz if you'd like to take a look. Obviously, it's tuned to the way I have my project arranged, but it shouldn't be hard to apply the principles to another project. The "explanation" file is a bit out of date, in that the system actually does some of the wishlist items.

Re:while we're at it, let's burn our Makefiles too

[iabervon]

I believe you're misunderstanding my use of includes. I'm suggesting using them for two purposes: (1) read simple files out of each directory which explain the contents of the directory as a set of readable variable definitions and (2) share code and have loops and subroutines in a tight set of scripts written together.

Build variations should be refactored until they come down to, essentially, "which parts of the code do I build". Then, based on simple cues from the user, you can build the right things.

My non-recursive make is for a project which has about nineteen targets which are either binaries or libraries; the one which is build depends on which directory you invoke make from. There is a make target to make a distribution, which includes everything needed for the target in the current directory and can be build from the root of the distribution.

The scalability issue is not with the number of build variations but with the number of types of build variations. Having a lot of dissimilar build variations is just a mess, regardless of what you're using to build with.

Oh good, It's just a software story

[Gil Da Janus]

For a moment there - seeing just the headline, I thought that the scientists were planning a revolt on the ISS.

Thank goodness, the last thing we need are some subverted scientists doing whatever in LEO!

Gil, just being a peanut gallery member

comparisons

[alyosha1]

Are there any good resources out there that compare available source control systems? My group is currently stuck on Visual Source Safe, but open to the idea of switching. I tried the trial version of bitkeeper, which looked pretty good though with a somewhat steep learning curve. The license was somewhat confusing as well. Basically anything that gives you visual merges/compares, lets multiple developers work on a project easily, and doesn't require you to run the "Analyse and Fix" tool weekly would be good...

Re:comparisons

[gbevin]

Personally I've switched all my projects to Subversion. It's simply the easiest to use and most versalite SCM software that I've ever used. The price is also great since as long as you participate in open logging you don't have to pay.
Before I was using AccuRev and besides the fact that it's not distributed it's a marvel (http://www.accurev.com). The gui tools are excellent and the support team is very helpful.

Re:comparisons

[wscott]

Perhaps you should have previewed that post at little longer? :-)

Re:MOD PARENT DOWN: OVERRATED

[Peyna]

Who cares either way? Your post was more pointless than mine, and this one is even more pointless. I used my +1 bonus because the person implied SourceSafe was a good alternative, when I think that pricetag makes it not an alternative at all for most people, especially those working on open source projects.

Besides, so many people post at +2 now, you almost have to hope to be heard above the noise. I browse at 3 most of the time, I'm sure many other people do too.

That's obvious!!

[Outland Traveller]

What is so bad about clearcase? From my point of view what *isn't* bad about clearcase is an easier question. Here's my hot list:

1. Needs kernel modifications in order to work. PROFOUNDLY STUPID. It's always an adventure trying to get clearcase to work with any recent linux kernel, and forget trying to keep current with kernel security patches.

2. "Filesystem" style sharing does not scale well outside of a high speed, local network. If your developers are distributed around the internet you need to use clearcase's horrible hack "snapshot" views, or shell out ridiculous amounts of money and complexity to implement multisite. It's very difficult from a performance and a security standpoint to use clearcase over a low-speed VPN.

3. Good GUI administration tools are windows-only. While rational could have created cross platform admin tools when they ported their product to Windows, they didn't. Instead they rewrote their admin tools to be windows only, added many new features, and now the windows tools are 200X more usable than their unix equivalents. When I pressed irRational when the unix tools would be similarly improved they gave the patronizing answer that unix customer's don't want good admin tools. Sounds like a self fullfilling prophesy to me. The unix GUI tools are so awful that it is easier to use the command line! Thus, irRational insures that unix shops with clearcase will always have a brick-wall style learning curve.

4. Vobs don't scale well, especially when you version large binary files, like media. You have to manually tune how many vobs to use and how large to make them.

5. Relies on automounting and persistent filesystem connections for day-to-day work. This design is inferior to a more traditional client-server TCP/IP app in terms of both performance and robustness.

6. Lack of commitment to the unix platform. iRational has stopped future development on their unix bug tracking software (DDTS) in favor of a MS-ACCESS backed solution. A large majority of new clearcase features are windows-only. You would think that Rational would be a cross platform company, but they are not. They make platform-specific solutions for multiple platforms, most of them purchased from some other company and poorly maintained.

7. Extremely high maintenance costs, not just in the licensing but in the dedicated personel needed to throw their careers away doing nothing but babysitting the vobs and views.

If you're buying a proprietary CMS the last thing you should consider is iRational clearcase. Try bitkeeper or perforce and you'll be much happier.

Re:That's obvious!!

[Feign Ram]

Kee -Rect ! The VFS used by Clearcase while providing a lot of it's cool features is also responsible for many drawbacks, including some of the ones you mention.

Scalability is the biggest downstream issue any manager has to consider before choosing Clearcase. It is extremely resource hungry and I used to work for a small company that deployed a Sun Enterprise server to support CLearcase for just 10-15 developers. Get ready with barrels of memory - shticks and drives.

The Steep learning curve is not something that u can wish away in a production environment.

In spite of all this, I remain fond of Clearcase - It was the first Version Control/Configuration System I used seriously and haven't found anything even remotely similar in terms of functionality. I felt like vomiting when I first used CVS after 4 years of CVS. Another nice feature is it integrates nicely with other Rational products like ClearDDTS the bug tracking system - Against a specific ticket you can check the list of related checkins/checkouts.

It was originally developed by a company called Atria and was later taken over by Rational.

And don't forget multisite. A Pig it is - but it provided lot of value for money, especially to comapnies that could afford it.

Re:That's obvious!!

[Bryan Ischo]

"I felt like vomiting when I first used CVS after 4 years of [Clearcase]."

That's funny ... because I felt like vomiting when I first used Clearcase after 4 years of CVS. Even the vague memories I have of Clearcase make me queasy just to think about ...

At my current job we use Perforce, which, although it has its own problems, is quite alot better than either CVS or Clearcase.

But subversion looks really good ... can't wait to play with it ... (I can't believe I'm excited about version control, if that's not the definition of a geek I don't know what is!) ...

Re:That's obvious!!

[AlanMJones]

1. Clearcase is admittedly new to Linux, but as for kernel modifications if you don't build your Linux kernel with what an application needs then yes of course you have to rebuild it with them if you want to run the application.

2. Yes Clearcase does require good connections if you plan to see all the updates in real time. But seeing updates in real time without a developer's manual or scheduled update of the local workspace is a benefit that not offered with many other systems.

3. Yes the windows GUI tools are better even in the latest versions of Clearcase. Windows users use them more than command line, many Unix users use command line more. I work with vobs hosted on Unix and accessible from both Unix and NT. The best of both worlds.

4. If you choose to check in large numbers of similar binary files that aren't diff'able then of course you're going to have to use lots of space. You don't have to do that to use the configuration record saving features of Clearcase. You have to tune only if you want great performance even though you went that unnecessary route.

5. The design allows a workspace to look just like a filesystem even though it can be manipulated by file version without changing the files you've modified. I can't speak to _how_ "inferior" it may be to TCP/IP but neither did you - you just said it was.

6. I thought we were talking about Clearcase, not issue and defect tracking tools. The DDTS replacement Clearquest can use Oracle instead of Access. All features that aren't GUI related are provided on both Unix and Windows.

7. Yes it costs money. It's a good product. It has features that can make parallel development easier than other source control tools. The people "babysitting" the vobs should be facilitating the developers. The vobs do their job with no help.

I don't work for Rational but I love Clearcase.

If you are in a small shop anything will do. If you want developers in 3 cities across the US to work together on the same project only Clearcase will do.

Re:That's obvious!!

[axxackall]

ALL Rational software products are designed so bad that I even doubt that there is any help from UML. Or is it that OOD/OOP so useless?

Re:That's obvious!!

[Outland Traveller]

1. Clearcase is admittedly new to Linux, but as for kernel modifications if you don't build your Linux kernel with what an application needs then yes of course you have to rebuild it with them if you want to run the application.

I don't think you understand the full meaning of the problem. There isn't any good reason why someone should mess with their their kernel to run a SCM *CLIENT*. The whole idea of this is off-the-charts idiotic. What makes it that much worse is that clearcase's kernel modifications are proprietary, and they only release them for certain older redhat kernels, and never the most up to date ones from any distribution. You're not easily able to use a custom kernel, as many people need to do for various driver support. You're also not easily able to add security patches to known vulnerabilities or even keep up with the maintenance kernel releases for your distribution. Furthermore, the clearcase modifications, because of their license taint the kernel hampering your community support for the rest of the OS.

This situation is damning, and not just for Linux. The clearcase MVFS features do not justify the "mess with the kernel" architecture. Their filesystem interface should have been implemented in userspace.

Reading your other points make me think that you haven't used SCM systems like perforce or bitkeeper. Your last line, " If you want developers in 3 cities across the US to work together on the same project only Clearcase will do." does not make any sense. Clearcase is a miserable choice for distributed development. It works, but in an ugly, brute force, memorize a stack of manuals, override all the normal unix commands, spend-a-fortune, have a department tuning and fixing it constantly type of way. As someone who has used many different systems, the clearcase way is so much more painful there is no comparision at all with modern alternatives.

The only people I see using clearcase now are companies that bought into it a decade ago when it was more competitive and have no idea what they are missing now, or small windows shops who are relieved that it is better than source safe.

Re:That's obvious!!

[Outland Traveller]

3. Yes the windows GUI tools are better even in the latest versions of Clearcase. Windows users use them more than command line, many Unix users use command line more. I work with vobs hosted on Unix and accessible from both Unix and NT. The best of both worlds. The right answer to "Should it provide a command line interface or a GUI" is of course "Both". Command line tools are excellent for scripting and for situations where all you need/want is a terminal interface. However, there is no denying that a GUI is an easier interface to learn, if for no other reason than the window visually encpasulates the functionality of the app much better than an off-line list of commands. As I said in the previous message, the clearcase GUI tools on unix are so awful that it visually hurts to use them. It looks like a summer intern wrote them in his spare time. It doesn't follow that because unix users hate bad GUIs, they therefore hate good GUIs.

In today's world there is no reason rational could not have made their rewritten GUI admin tools cross platform. There's the QT library, there's JAVA, there's web browsers, and those are just the solutions that pop off the top of my head. Instead, they doggedly rewrite for one platform only and say that they have no plans to port the new tools to the other platforms. What kind of crap is this? I have a sneaking suspicion that the windows clearcase server and unix clearcase server are not even intercompatible with each other's clients.

This is the kind of marketing decision that occurs when a company is so obsessed with short term growth that they compromise their core competencies. This has been the story of irRational across the board. Buy their products at your own risk.

Re:why does subversion exist?

[ebuck]

Subversion exists because every now and then, after doing tons of patching, fixing, feature adding, and code tweaking you realize that if you started with a different sort of code architecture life would be easier.

The CVS guys are working on subversion, but "fixing" CVS would not necessairly be the best way to fix their problems. Massive changes in CVS would raise a cry of desperation from the masses of programmers that rely on CVS for day-to-day operation. Also, if it is discovered that a totally new way of handling things is much better than the way CVS works, you encounter nasty if not impossible upgrade difficulties.

People don't want to put their code at risk. Too much time and money goes into it. Subversion "solves" the migration problem by making a totally new project.

arch vs Subversion

[Luyseyal]

Here is short comparison of why you might want to use arch over Subversion, depending on your project's needs:

http://regexps.com/src/src/arch/=FAQS/subversion

-l

Re:arch vs Subversion

[William Tanksley]

It's hard to read a document which starts out so fundamentally /wrong/. It claims that using "ordinary files" makes its format somehow more managable -- what baloney. By using "ordinary files" it's actually choosing to implement its own proprietary database. If you want to manage it, you have to learn its format.

Subversion's not ahead here; but by using a standard database, at least you can use standard database tools to manage it. You still have to learn, of course.

I like arch. It's a cool system. But nonsense like that...

-Billy

Re:arch vs Subversion

[joib]

Hrm.. arch is cool in it's own right, no need to bash subversion. They have different goals.

The goal of subversion is to be as similar to cvs as possible, while correcting the big flaws in cvs. If you want, think of Subversion as CVS 2.0. While the backend is quite different, the command-line client is quite similar to cvs, it accepts many of the same options as cvs. Developers familiar with cvs should be almost immidiately productive with subversion. The subversion guys are even developing cvs2svn repository migration tools. Also, subversion has a client API, making writing GUI clients and the like much easier.

Arch, however, is different. Migrating from cvs to arch is not as painless as from cvs to subversion. That being said, arch supports distributed repositories, which subversion doesn't, and has oodles of fancy merge operations. Also, arch consists of about 40klines of mostly shell and awk scripts, which makes some people shudder. This also means that getting arch to run on a non-Unix platform is probably next to impossible, while subversion can run on any platform apache supports (Yes, the client and libs also use APR). Finally, arch currently uses ftp as transport protocol, making it problematic security-wise.

Re:arch vs Subversion

[millette]

Seriously, if we had a good enough filesystem, there wouldn't be a need for any db. It's only a question of point of view. You mention using standard database tools to manage subversion. What's so wrong about standard filesystem tools to manage arch then? You know, like cat and grep, and ls even. (Please, don't point out that grep isn't a filesystem tool, please).

Re:arch vs Subversion

[Luyseyal]

1) I'm not bashing Subversion. Reread what I said.

2) The author isn't bashing Subversion. His point is he thinks arch has some better features, particularly for open source-style development.

3) bash and awk both run on Windows and Mac. The author says (in another document on the website) there's also a Perl version in the works.

4) ftp is not an issue since ssh can masquerade ftp well enough.

-l

Re:arch vs Subversion

[Luyseyal]

The point is that having a local archive of all the versions allows you, for example, to grep through the source for that old snippet of code in some version that you need but aren't sure what version it's in. Sure, you can checkout all the Subversion versions locally, but arch does it implicitly. I think that's pretty sweet.

dig around in here to get an idea of what the file tree looks like:

http://regexps.com/src/src/arch/%7barch%7d/

-l

Re:arch vs Subversion

[William Tanksley]

You mention using standard database tools to manage subversion. What's so wrong about standard filesystem tools to manage arch then?

Nothing. Nothing's wrong with using standard filesystem tools to manage arch. Nothing's wrong with arch -- or at least I have nothing to criticise.

What's wrong is arch's idiodic propaganda stating that Subversion is magically inferior because it uses a database rather than a file system.

The one weakness in arch is that it manages the existing filesystem as a database but accepts the use of non-database tools to alter it. You can use grep and so on to maintain it, but you'll certainly destroy it if you don't know exactly what you're doing, since filesystem tools can't possibly know how to maintain a database, while database tools must.

But this isn't a big deal to me -- after all, you can have a perfectly good database which isn't a version control system, so your database management tools can cause a lot of problems as well when used by an idiot. So again, I have no complaints with arch's approach. Only its marketing.

-Billy

Re:arch vs Subversion

[William Tanksley]

Why are you replying to me with this? It doesn't seem to fit any of my posts. Perhaps you meant to reply to someone else?

-Billy

Re:arch vs Subversion

[Luyseyal]

I was simply pointing out why arch's "ordinary files" are more managable, from a code perspective, than databases.

-l

Re:arch vs Subversion

[millette]

Thanks for clarifying your point. I wasn't saying anything for/against arch/subversion either. In reallity, I was thinking about something Hans Reiser said: "That way, users can continue using the filesystem directly rather than building special-purpose layers that run on top of the filesystem, such as databases and the like.". quote

So my post was more theoretical in nature. I guess you can even consider it off-topic now.

Re:arch vs Subversion

[William Tanksley]

Okay. Why did you compare local version storage versus remote version storage, then? This isn't a database versus files issue; it's a local versus remote issue.

Anyhow, I certainly agree that arch has this, and other, advantages. (Many others.) None of them make arch "more managable" or "more usable" or anything else than subversion; they simply give the two different characteristics. Remote files have HUGE advantages as well, in the right environment.

-Billy

Re:arch vs Subversion

[Jerf]

To whomever wrote that document: Speaking as a disinterested third party with some experience, the document does not look like a "short comparision", it looks like a Subversion bash fest written by somebody with an axe to grind.

As a simple example, consider

In Subversion, a lot of revision control "smarts" are built into the server. In arch, the smarts reside entirely within the clients. Therefore....

1. arch is very fast
2. arch is scalable
3. arch servers are easy to administer
4. arch is resiliant when servers fail
5. arch is better able to recover from server disasters

(numbered for my convenience)

However, this characterization is horribly, obviously lopsided in favor of arch. Putting the smarts on the server is a good thing, because it prevents replication and therefore differences and therefore bugs on the client side, with logic the client should not need to deal with. It makes it harder to write an arch client correctly (witness the profusion of cvs clients).

1 does not follow; a server can often do things faster then a client, because the client may be slow while the server is an 8GHz quad-Sexium with 8 gigs of RAM.

2 does not follow as an advantage; there's nothing that says a server-based solution can't scale, they do all the time.

3 is true, but you're trading off with an entire system (server + clients) that's harder to program correctly because of rampant logic duplications in the clients. It's not an unmitigated advantage in favor of arch, and in fact I read it as an advantage to Subversion.

4 is a nonsequitor; it may be true but it does not follow from being non-centralized. Same for 5. Again, there's no law that servers must be difficult to recover failure from.

This is just one example of an attitude that pervades the linked document. In fact, the article pointed does more to turn me off to arch then anything else. If the author was a developer for arch, I'd be concerned at the lack of experience in design (it is almost never the case that one solution is better then another in every way) and inability to fairly evaluate two products (why not show what both are good for?) being shown here.

Re:arch vs Subversion

[William Tanksley]

Oh, I agree with you entirely, then. Yes, I've also been watching ReiserFS for some time.

I have to note, though, that high performance databases don't run as layers on top of the filesystem; they run directly on the drives, with no filesystem intervention. ReiserFS won't change that; it may be better than ext2fs for database tasks, but it's still not tuned for big-league work. And it never will be -- it's not targetted for that.

-Billy

Re:arch vs Subversion

[joib]

1) I didn't say that you were bashing subversion.

2) Ok, maybe bashing is a too harsh word, but I'd hardly say his comparison is unbiased.

3) Yes but there are other things like hard links etc (like almost the entire unix tool chain). A quick search on google finds the author saying himself that arch is only for POSIX environments.

4) Even if it works when you use passive mode ftp, you still need shell access for ssh. Anyway, maybe this isn't such a big problem since there are patches for webdav support. Maybe they'll get integrated into the main tree soon.

Bottom line: both of these will easily blow cvs out of the water. Use whatever you like.

Re:arch vs Subversion

[Luyseyal]

Bottom line: both of these will easily blow cvs out of the water. Use whatever you like.

right, which was the point of my original post:

Here is short comparison of why you might want to use arch over Subversion, depending on your project's needs

-l

Re:arch vs Subversion

[Luyseyal]

The point of distributed archives is replication. It's fundamental to the design. It assumes you live in an often disconnected world and you can sit there with your laptop in the middle of nowhere doing merges and whatnot independent of some remote archive.

Anyway, that's the point of it. If it doesn't fit your environment, you shouldn't use it. :)

using your enumeration:

[1]. The problem is he doesn't define "fast". When I think "slow", I'm thinking being on the slow end of a pserver/webdav connection in a large project with a lot of concurrent branches in need of merging. Still, I agree, if you can afford the server and all the clients have a decent connection.

[2]. Well, server-based solutions are expensive on the Linus Torvalds level. Have you seen the merges that guy does? Scary.

[3]. You're right, except that there are no arch servers (by server, I'm guessing the guy means "main ftp archive" or something). But sometimes it's better to have a smart client. I definitely don't want Apache trying to render web pages for me... sending an image to a dumb browser, no matter how annoying IE vs Mozilla incompatibility gets! :) But yeah, in a highly centralized, probably corporate-style, environment, arch is probably not as good a fit as Subversion.

[4] & [5] follow from being decentralized because the distributed trees all maintain the history. It obviates the need to specifically keep mirrors of the main archive around since each local archive is already a mirror. At least, that's my understanding of it.

As far as the author is concerned, I'm guessing he's just trying to advertise his wares. He may have failed due to his poor writing, but I'm guessing his goal was marketing. You might contact him about it... you know: download arch, get a copy of his tree, write up a patch, and publish the archive. hehehehe

-l

Re:arch vs Subversion

[Jerf]

I wasn't really interested in giving exhaustively correct answers myself, as I've used neither.

He may have failed due to his poor writing, but I'm guessing his goal was marketing. You might contact him about it... you know: download arch, get a copy of his tree, write up a patch, and publish the archive. hehehehe

"Marketing" open source is an interesting issue. I think the issues involved in attracting developers and users to your project are not well explored by the community. There should be a 'definitive essay' on the topic, as in 'Homesteading the Noosphere". (I intend to write one in a few years, if my projects are released and do well. Failing that, I'm not qualified, so don't ask me to do it. ;-) )

See, the author here has already turned me off and lost. Marketing Open Source should be more honest... 'here's what it's good for, here's what it isn't, here's what needs more work'.

Re:arch vs Subversion

[fferreres]

Either make the filesystem DB oriented, or let people use DBs. The flexibility of a DB on top of a filesystem is that you can keep the OS simple and extend it using whatever DB you want to use, or multiple DBs or no DB at all.

The benefit of a DB based filesystem (direction of ReiserFS4) are also great. It may be the case that you'll not need a separate DB (but maybe you will, if you need other features!).

MS going to a DB filesystem will make our lives more difficult for sure. We just need to way and see, but that's my guess. And they can make it work, because the can force a single DB filesystem you cannot avoid.

On the other hand, Linux will probably have options for DB filesystem, but as they will not be widespread (and there may be a lot of incompatible DB fs) for a long time, you can't sucessfully base aan app on a specific DB fs beign at the core.

This my semi-uneducated opinion of course.

Re:arch vs Subversion

[tomlord]

Um, hey -- I think I'm now obligated to all your reading skills into question ;-)

It's a FAQ, not a paper. In other words, its designed to help orient readers to the design space and give them a staring point for research and comparison. I assume that the FAQ's readers are smart enough not to try to use the FAQ as a CS textbook.

Second, what I've tried to say in the FAQ is not that databases are overapplied (that's for another discussion) but rather that arch's standard-file-formats and ordinary filesystem tree orientation resulted in a very tiny, simple implementation that nevertheless has many of the desirable semantic and performance characteristics people often presume require a database.

That second point isn't some loopy overgeneralization about databases: it's an observation about how the implementation "came together" around simple file formats.

But yeah, thanks for the reminder that when we really do get around to having the "proper role of BTREEs" debate, that, in light of all the accumulated wisdom on the topic, I'd better speak very carefully.

Re:arch vs Subversion

[William Tanksley]

It's a FAQ, not a paper. In other words, its designed to help orient readers to the design space and give them a staring point for research and comparison. I assume that the FAQ's readers are smart enough not to try to use the FAQ as a CS textbook.

What on earth does that have to do with your claim that "with arch, you can use standard tools to access past revisions" (implying VERY specifically that you can't do that with Subversion). The entire point of the document is to compare Subversion and arch; instead, you're allegedly comparing databases versus file systems.

"Allegedly" because you're actually comparing your special-purpose database to Subversion's use of BDB (or whatever they switch to when they've had enough of that).

That second point isn't some loopy overgeneralization about databases: it's an observation about how the implementation "came together" around simple file formats.

In a FAQ about the history of arch, that makes sense. In a FAQ about comparing Subversion versus arch, it doesn't. Frankly, your statement here doesn't even make sense, considering what you're actually SAYING in that document. You're NOT giving a history; you're making a very specific claim about present capability.

I'm REALLY impressed with arch. I like the documentation I've read, like the software. I'm not an enemy. But I HATE, abhor, detest this kind of sniping against other projects.

Second, what I've tried to say in the FAQ is not that databases are overapplied (that's for another discussion) but rather that arch's standard-file-formats and ordinary filesystem tree orientation resulted in a very tiny, simple implementation that nevertheless has many of the desirable semantic and performance characteristics people often presume require a database.

Again, context is very important. The context of this FAQ is a contrast between Subversion and arch; in this FAQ, any bullet list claiming a feature especially for arch is implicitly a claim that the same feature is unavailable or very difficult in Subversion.

In fact, I would definitely say that by the definition of the term "database" you've written your own database. It's probably not relational, but RDBs aren't the only type, nor are they unambiguously the best. So you aren't scoring any points on the "databases are not needed" scoreboard. All you're doing is proving "I can write my own database which serves my needs better than some general-purpose database" (I would tend to agree, even without the beautiful evidence of arch to support your argument).

Of course, this sort of claim doesn't belong in a comparison with Subversion either, although it's certainly worth some good discussion.

You know what, I'm wondering if you're talking about the same FAQ I am. Look at the link which started this, and make sure we're on the same page.

With all due respect, maybe I'm not the one who needs to work on his reading comprehension ;-).

-Billy

Google Cache

[RicRoc]

Get the goodness here!

I've been using CVS for some time and I'm happy with it, but if the same guys think they can make something better, great! I'll try it ASAP. :-)

ssl

[sllort]

Just out of curiosity, does subversion have a solution to the CVS's insecure :pserver: problem? That is, a better hack than the nasty scvs scripts for those of us who can't afford to use insecure version control?

I couldn't find any mention of it on the web page, which is why I'm asking here.

Re:ssl

[Anonymous Coward]

Subversion uses Apache for it's network communication, and I beleive you can use https instead of http.

Re:ssl

[kaisyain]

The web page says they use Apache for all of their networking. That means you get SSL for free.

Re:ssl

[TTimo]

why can't you use straight :ext: and ssh method instead of that scvs thing

Re:ssl

[joib]

As it says right on the front page, Subversion uses WebDAV as its transport protocol. As webdav is based on HTTP 1.1 you get all the benefits of HTTP, like for example SSL encryption.

Re:ssl

[joib]

Quoting AC:

So the client is entirely web based? How do you checkin code? Paste it into a web browser?

No, the client is a command-line client, like cvs. It just uses HTTP (or to be more specific WebDAV, a HTTP extension) to communicate with the server.

Re:ssl

[ftobin]

Ugh, how awful. One of the things I love about CVS is that it can run over ssh.

Re:ssl

[be-fan]

Exactly why do you care what protocol the server uses? If HTTP is good enough for credit card numbers, it should be good enough for a source control system.

Re:ssl

[ftobin]

I care becuase ssh has agent forwarding, public-key authentication, port tunnelling, and much more. All of this I care about, and use in conjunction with CVS and other things.

The entire user-agent system for HTTP(S) is incredibly crappy compared to what ssh provides.

Re:ssl

[GoRK]

So tunnel subversion over ssh. Do your key auth and port 80 redirection with ssh, then use subversion just like the server was running on your local machine.

Re:ssl

[TTimo]

indeed, I don't see any true security and features difference between running cvs through ssh or accessing svn repository through ssl.

Re:ssl

[MassacrE]

The only real difference is that connecting CVS via SSH means that users require shell accounts.

The name

[jbucher]

Did it occur to the developers that the name subversion does not inspire confidence in a software management package.

At least they did not call it Kontrol, or gSource gManager.

Re:The name

[TTimo]

Stuff like Kontrol gSource .. gManager .. hugh, that sounds like a big lack of creativity.

At least 'subversion' plays with the word 'version' and turns it into something cool.

CVS isn't being developed

[mgkimsal2]

his service seems to be redundant and will probably not stay up to date with CVS or else CVS will not stay current with it either way it doesnt seem to make sense IMO

Having adopted CVS for most projects in the past couple years, I beat my head against the wall with many, imo, stupid issues with CVS. I assume that you don't use CVS, or you would be familiar with the fact that CVS pretty much isn't maintained/extended anymore. What's there is there, and has been *mostly* unchanged for years. There may have been a few patches here and there, but if it was being upgraded/extended, the issues that are 'stupid' now (diretories, permissions, etc) would have been fixed years ago.

Microsoft doesn't even use its own products ...

[BitMan]

Here's a list ...

• DNS: Only a handful internal Win2K DNS/AD Servers, 0 external, numerous ActiveDirectory issues (let alone DNS changes done "on-the-fly" that takes them down weekly)
• Firewall/Proxy: Virtually 0 ISA Servers
• SCM: No team larger than 50 using Visual Source Safe

Re:Microsoft doesn't even use its own products ...

[bmajik]

Not quite:

There are lots and lots of DNS/AD servers at MS, although not as many running W2k anymore (they're running W2k + 1 mostly)

And, unfortuneately, we have LOTS of boxes running ISA server. On numerous occasions i've emailed the relevant admins saying "please let me setup 1 squid box for you so i dont have to put up with this crap anymore". It's gotten better but man dogfooding is painful sometimes.

I can think of 1 team larger than 50 using VSS. There's an internal-only project spread over several teams that has been the same source base for 4+ years that is using VSS. There are easily over 50 people who've made checkins. Thats probably different than 50 active developers.

You're generally right though about VSS - it's not being used anymore internally for large projects. It's an adequate SCM for small projects or groups of small projects. The project I mentioned has about 5GB under VSS control and it works reasonably well, but I probably wouldn't start with VSS if i were starting from scratch.

versus jakarta slide?

[awb131]

Does anyone know how subversion compares with Slide from the Jakarta Project? Slide is also a WebDAV/DeltaV client and server. In the past, I've been more interested in Slide because it has a more "pluggable" back end (Slide is in Java, and I am a pretty good Java programmer, not so much with the C.) Easier to embed/extend for my own uses.

For example, are the two interoperable in any way? Can you use one's client to talk to the other?

Re:versus jakarta slide?

[alienmole]

Since Slide is not specifically intended for source code management, I would imagine subversion has many features in this area that Slide does not. However, I haven't used either, only read about them.

If you're looking for something to embed/extend and you know Java, then Slide would make sense, especially if you're planning to use it for something other than source code management. However, you might still want to use subversion for the source of that project... Most people don't need to extend their source code manager much, except perhaps with a few scripts.

Re:versus jakarta slide?

[danielrall]

Subversion is very pluggable in on the server side. This pluggability may extend to the client as well (but I'm not certain).

Re:why does subversion exist?

[zrodney]

After a decade (has CVS been around longer?)

ha ha ha ! yes. cvs, is much much older than
1992

maybe we should start a thread about cvs vs sccs now?

Sourcesafe isn't that bad.

[Otis_INF]

For small (less than 200.000 lines of code) projects it's pretty good. You should know the limits like the size of the database shouldn't exceed 1GB, but overall the tool works seemlessly. Here we have over 20 projects in several databases and haven't found any problem with it since we started using it back in 1999. (Yes we check for errors ;) ). For the small price-tag it has, it has a lot of features and a nice gui, which supports visual conflict resolving, drag/drop sharing/branching etc.

You shouldn't use it for large projects. So when people still use it for large projects, it can be cumbersome and slow.

So your 'it's a total piece of shit' is way off base, or you're one of these people who cram 1.5 million lines projects in Sourcesafe and then start complaining.

Re:Sourcesafe isn't that bad.

[crouchingpenguin]

Haven't we done this before ?

Yes this is way off topic... but

"You shouldn't use it for large projects. So when people still use it for large projects, it can be cumbersome and slow.

So your 'it's a total piece of shit' is way off base, or you're one of these people who cram 1.5 million lines projects in Sourcesafe and then start complaining."

blah blah... thats not a real project. If your loosy SCM cannot scale past 200k lines of code, then what good is it? Your "way off base" in this case is way off base itself.

Re:Sourcesafe isn't that bad.

[tpv]

... thats not a real project. If your loosy SCM cannot scale past 200k lines of code, then what good is it?

Well it would seem it's perfectly good for 199k lines of code.
Although in the case of VSS the limit seems to be somewhere between 1 and 10 million lines of code (based on anecdotal evidence - I don't use VSS).

Seriously - if a team of 5 VB developers want to use VSS to manage their 50k LOC project, what problems will they face?

My own bad experience 9 years ago

[A nonymous Coward]

My little group (4 programmers) had been using CVS for years, and another group (10 programmers) installed ClearCase, and management decided our CVS group should convert. There were two CC admins; one wrote a piss poor install script. When it started deleting files it had no business even looking at, I aborted it, cleaned things up (*I* kept backups :-), told my boss, and he backed me up -- we stayed on CVS. The other CC admin was a joke, and twice (!) deleted the CC repository by mistake. Other times I don't know what he did, or if it was just CC taking a dive, but they were down all day getting it straightened out. Most of that group were envious that my group stayed on CVS.

I have never worked on huge projects, never more than a dozen programmers at most, and CVS has always been good enough. I will certainly switch to subversion, or maybe one of the others, because I like a lot of the improvements, but CC has always seemed like bloated overkill.

Seems like too much baggage

[SilentTristero]

We use CVS here, and like everyone else I'm fed up with the lack of rename support and branching. But looking at the install requirements of Subversion is very intimidating! It requires:
- Berkeley DB, a particular version (this makes sense)
- Apache 2.x
- WebDAV
- Neon
and a bunch of other stuff, IIRC. (Their site is /.ed, so I can't check, sorry)
All we need at my company is a server to run on one Linux machine and clients for all the others (MacOSX/WinXP/Linux/IRIX), all within our firewall.

Doesn't all the above stuff, especially the Apache/WebDAV/Neon stuff, seem like overkill just to implement a network protocol for a version control system? Setting up a CVS server is certainly not this complicated, and it seems like with a little more effort on the developers' part, much end-user time and pain could be saved. Does Apache/WebDAV/Neon really buy enough so it's worth the install&admin overhead?

I'm not trying to rag on the Subversion developers; it looks like a really cool system, once you get it up & running. It also looks like they've really done a great job of meeting their goals. I'm definitely looking forward to checking it out -- as soon as I have enough time.

Re:Seems like too much baggage

[TTimo]

In the long run, you will just get your svn client or server from a rpm or a deb or whatever.

The bootstrap tarball has very good documentation. A bunch of stuff to download and install, but no major difficulty really.

Re:Seems like too much baggage

[be-fan]

Actually, the install's not that bad. You download and compile berkeley db 4.0.14. Get apache from CVS and compile that. Download the subversion tarball, and compile that. Use that version to checkout a new version from the repository, wget neon and untar it, and compile it. Then, just edit the apache config file. The nice thing about it is that while it is long, the install document is *extremely* precise. It basically tells you exactly what commands to type in. Editing the apache config, file, for example, had the potential to be disastrous for someone like me who had never set up apache before. Yet, I just copied what it said in the config file, and it worked! The configure script is also very good. It makes sure to properly check all the dependencies, and installing a missing one is a matter of reading the very helpful error message and typing in [urpmi/emerge/apt-get install] "offending-library."

Re:Seems like too much baggage

[be-fan]

Well the nice thing about it is that it uses tools that already exist, so they get client/server essentially for free. WebDAV, for example, is an existing protocol for document versioning over networks. Makes it a perfect fit for this. Also, because it uses Apache, it can take advantage of the proven security and stability of the server. What would be bad is if Subversion rolled its own server and protocol.

Re:Seems like too much baggage

[Russ Steffen]

You are overstating the requirements a bit. WebDAV is part of Apache 2, and Apache 2 is only required for remote access to the repository. The only real dependancies are Neon, BerkelyDB 4, which, at least for linux, will likely be included in the next generationj of distributions as Berkeley DB 3 and 2 are now. A neon is justa small shared library, not that big of a deal.

Look at it this way, by the time Subversion is released the packages it depends on will be standard parts of most Linux distributions and will be staples in the *BSD ports system if they aren't already. Subversion will just snap right in.

And I have to disagree about administrative overhead. By integrating with Apache, it's one less network service to configure, plus you get to take advantage of Apache's authentication modules, and you get web repository access with no extra setup.

Re:Seems like too much baggage

[Garrett Rooney]

Listing 'WebDAV' as a separate requirement makes very little sense.

'WebDAV' is a protocol. 'Neon' is a client library we (Subversion) use to speak that protocol. 'Apache' is a server that provides an implementation of the protocol that we use in our server.

So yes, we require Neon for building the client, and Berkeley DB if you want to access a repository directly (either for a local repository or if you're building a server), and Apache if you want to run a server. These requirements don't seem to crazy to me, and if you don't want to mess with them yourself, download a package. There are RPM's and a FreeBSD port (I think both still need to be updated for alpha, but I'll be doing that for the FreeBSD port tonight, and the RPM's are always updated pretty quick).

-garrett

Re:Seems like too much baggage

[SilentTristero]

Several folks pointed out that WebDAV is a protocol that comes with Apache. Sorry, my mistake -- I didn't read the docs carefully enough. Well, I'll put my money where my mouth is: I'm trying it right now. It's taken two hours so far.

APR was dead simple. (No RPM available, but not needed.)

Autoconf: I had a version of autoconf in /usr/bin, and the version subversion needs autoconfig'ed into /usr/local (of course). I fiddled with that, OK. (RPM available.)

libtool 1.4: no problem. (RPM available.)

I downloaded neon, and subversion built it automatically. (RPM available, but I didn't use it.)

Berkeley DB was pretty simple, except that the whole subdir of docs/ that explains the build process was missing in my download -- I found the instructions on the web. This also created errors when doing the 'make install', had to use make -k to work around them. (No RPM for this version available.)

However, when I went to configure subversion, it didn't recognize my Berkeley DB install (in the default place, /usr/local/BerkeleyDB.4.0), so I just copied it into the subversion build tree and it built it OK.

As for apache, the first thing is subversion requires 2.0.40, but the latest I can find is 2.0.39. OK, so I figured out that means I need the latest CVS version. Also, I already have an older 1.3.xx version running because RT requires it, so now I have two versions running simultaneously! A bit of an admin hassle, but again, not a showstopper. (No RPM available for this version.)

(I also installed python 2.0, which required a bunch of other stuff, but I gather that was optional.)

I guess, from the comments I've seen, that I'm the only one who thinks it's weird to require people to install a web server just to do source control (with more than one machine). HOWEVER: now that I've started to try it out, I have to say it's really a pretty cool idea. It might even be useful to my company!

I expect all this will get much simpler, but for now it's not for the faint of heart. Still, from what I can tell I think subversion will be the best post-CVS CVS!

Re:Seems like too much baggage

[slipsuss]

Keep in mind: you only need to build Apache 2.0 if you want to create a Subversion *server*, i.e. network your repository.

But you can just as easily build a Subversion client that has BerkeleyDB linked into it; you'd still be able to create and access a repository on local disk.

In other words, it's relatively simple to build and use Subversion for "personal" use -- say, on a box where you don't have installation privs. Just use it in your home directory.

Re:Seems like too much baggage

[SilentTristero]

[Single-user doesn't require Apache.] That's cool. I wonder if it wouldn't be possible to just use samba and nfs to access a repository database without needing any server protocol. Locking might be an issue, perhaps, but maybe Berkeley DB can handle that? Well anyway, I guess it's better to just use Apache as intended.

Re:Seems like too much baggage

[slipsuss]

Berkeley DB doesn't work over NFS. NFS can't supply the locking it needs. :-(

Re:Seems like too much baggage

[SurfsUp]

But looking at the install requirements of Subversion is very intimidating!

I did:

sudo apt-get install subversion

Voila! Installed, configured. It's just a little older than today's alpha (.13) but I don't mind. It will automatically update to the latest version in a few days.

I've been using Subversion for three months...

[Ludwig668]

... and have been really happy with it. Setting it up is a thesis project (the most common problem with software that's free) but once that was done, it works beautifully.

SCC works well for several purposes:

• Backup--I save everything in a personal 'svndocs' directory; including stuff like quicken databases, word documents, all that stuff. Just 'svn commit' (or in my previous life, 'cvs commit') and you have your backup stored on another computer. I had a laptop die at a customer's site, and it took downloading the client and 20 minutes to resume development on another computer. My brownie point score soared.
• Share files with customers which are far away. SCC acts like a low-bandwidth file server. There are suddenly no hassles putting together installers and such; so the rate at which you can deploy updates greatly increases. CVS really sucks when it comes to directory versioning, that's why I switched to SVN. I can now configure the whole deployment tree on my side, and don't have to start e-mails with 'well, because CVS can't do this, you need to delete the whole project and check out over again.' Monkeying around with directories is much more important, considering the way that ant relies on java files being in directories which correspond to their package names.

Re:MOD PARENT DOWN: OVERRATED

[Peyna]

Actually, I usually forget I post at 2. I wish there was an option in the settings to always post at 1, but there isn't, so I have to remember to check "No Score +1 Bonus" whenever I want to post lower. I would rather it be the other way. Always post at 1, and have to manually decide to post higher. I usually type, then tab,tab,tab,enter real quick.

Re:Questions about scons

[diewarzau]

As a developer of SCons, I'd like to address the "annoyances" above:

"Unless you don't know Python. I never figured make syntax to be very difficult."

Neither is Python, and Python is much more powerful. I've seen makefiles for complex build processes, and they are nigh unreadable. Even if you don't know Python already, we considered the choice of a well-established, actively developed, powerful scripting language to be superior to the invention of Yet Another Mini Language.

"I didn't realize this was an improvement over make, which is pretty language-agnostic. What about other languages? I usually assume listing specific elements means unlisted elements are NOT supported."

You know what they say about assuming... I'll stipulate that the exact meaning of this statement is unclear at first glance. However, consider one of SCons's other features...automated dependency generation. In order to do that, SCons must have a dependency generator for that particular language (to parse #include's, etc.) Users can add their own dependency generators as well. SCons *will* support any language just like make, as long as you can put up with specifying dependencies explicitly for "unsupported" languages, just like make.

SCons also makes it much easier than make to set up builds, since it already has some built-in knowledge of the way certain tools work. All of this is of course user-extensible, but we provide built-in support for some common tools.

"That -j option look like they borrowed it from make"

Okay, yes, we did borrow that from make.

"Not sure exactly what this means, but make understands RCS and SCCS, IIRC. Been a while since I used the feature"

SCons does not integrate with a specific source control system, but it does allow you to specify multiple directories (repositories) that will be searched for files before they are built or taken from the host machine. This allows building from a server, or even multiple servers. I think this is akin to make's "VPATH" support, but AFAIK it is more flexible.

Come and see SCons and judge for yourself. I find it alredy vastly superior to make for large-scale, highly variant projects (or any project!) Of course, I am biased, since I wrote a large part of it, but I did so because I found existing tools insufficient.

www.scons.org

Emacs support

[mmynsted]

This begs the question, How may I get involved in a
project to integrate this with Emacs, e.g. with
Emacs VC or some new interface? :-)

Anybody working on this from an Emacs standpoint?
I would love to help in some capacity.

Re:Emacs support

[slipsuss]

We've already got the beginnings of VC-mode support. The .el file is in the subversion source tree.

Unfortunately, the VC API doesn't exactly match up with subversion concepts. So people have been batting around ideas to revamp the API for pcl-cvs, or maybe inventing a new API.

Re:Will Subversion guarantee backwards compatabili

[Logic]

That's one of the nice things about Subversion; if the repository format changes, you have two tools ("svnadmin dump" and "svnadmin load") at your disposal to export a repository to an intermediate XML format, and then re-import it into a more recent version. They've had to change the on-disk format a few times during development, and this dump/load functionality has been invaluable for handling cases like this.

Re:MOD PARENT DOWN: OVERRATED

[frankie]

I wish there was an option in the settings to always post at 1

There is. Go to your Comment Preferences and scroll down to the bottom section.

oh no!

[r00tarded]

from the bang-on-it-if-that's-your-thing dept.
How did you know what I was doing? Did someone stick an X10 in my bedroom?

How about migration tools from CVS?

[iabervon]

It would be very useful if they had tools for making a subversion repository from a CVS repository, keeping all the history, because people who are now using CVS won't want to lose their historical info. Since the features seem to be a superset of CVS's features, the only problem would be that the pre-subversion history would look odd where people did things to work around missing features.

Re:How about migration tools from CVS?

[slipsuss]

We've got python bindings for parsing RCS files, and bindings to subversion libraries (via SWIG). As a result, we now have a good start on a 'cvs2svn.py' repository-converter script.

The script examines the cvs repository, deduces changesets, and commits them to an svn repository. It works right now.

However, it doesn't yet convert cvs branches and tags. We're working on it.

...Also known as "Compaq-ted"

[n9fzx]

Oops, sorry, wrong Alpha...

Re:MOD PARENT DOWN: OVERRATED

[Peyna]

It must be new, I checked quite awhile ago and it wasn't there.

Two words

[mypalmike]

Atomic Commits!!!

Re:That's obvious! Is it??

[joshsnow]

When I pressed irRational when the unix tools would be similarly improved they gave the patronizing answer that unix customer's don't want good admin tools.
Was this really what was said, or did they say, "unix customers don't want to use GUIs"??
Seems to me from reading Slashdot regularly, that *nix people prefer command lines for sys admin/programming/source control stuff. Plus when writing code for windows, it's natural to include a GUI for apps which have user interaction.
Meanwhile, in the *nix world, first you have to decide which toolkit to use, then you need to decided if that's going to fit your chosen programming language etc. It's a different ballgame.
For instance, does subversion have a GUI?

How about adding ssh support?

[alwyns]

One of the great things about CVS is that I can use ssh with it,
it gives me the following advantages:
1) I can access CVS server indirectly by doing tunneling.
2) My code is encrypted on the wire so I can access it over public
networks without the possibility of someone hijacking it.
3) I can use PKI to authenticate someone to the CVS. (not as
important to me as the fact that data is encrypted)

Now I've heard people coming up with solutions like using .htaccess
and SSL. Why would I want to use SSL if I can use ssh? Are all
of us now suddenly supposed to be openssl coders? It must be
easy for people to develop tools like cervisia for subversion (with
SSL)...

I think..

[Inoshiro]

If you're whacking it to Slashdot, you have larger problems than people watching you flog the dolphin ;)

CVS is old....

[jit]

The original shell-script version is dated somewhere around 1986, the translation to c is from around 1990.

Here's some more info, including some ancient material wrt cvs: http://www.cs.vu.nl/~dick/CVS.html