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.

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: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: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!).

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.

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: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

[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: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.

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: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.

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.