Slashdot Mirror
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.
Just use some of the perfectly good source control programs out there. Visual Basic Source-Safe comes to mind.
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).
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
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!).
Rod Taylor
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.
Ant has some pretty cool features (and a few misfeatures, sadly), but it's really caught on in Java-land.
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.
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.
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
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
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.
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.
Never underestimate the relief of true separation of Religion and State.
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.
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.
Infuriate left and right
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.
SCC works well for several purposes:
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.
My opinions are my own, and do not necessarily represent those of my employer.
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.
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:
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.
A deep unwavering belief is a sure sign you're missing something...
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?
four-oh-four
Noone in their right minds uses this.
It's a 'kludge' that works extremely well, and fits well into the unix philosophy.
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).
True. But this has little to do with the transport protocol.
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.