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.
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
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.
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
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.
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.
Also, check out jam. It's by the same people that brought you perforce.
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!
Subversion uses Apache for it's network communication, and I beleive you can use https instead of http.
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.
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.
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
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:
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
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.
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.
/usr/bin, and the version subversion needs autoconfig'ed into /usr/local (of course). I fiddled with that, OK. (RPM available.)
/usr/local/BerkeleyDB.4.0), so I just copied it into the subversion build tree and it built it OK.
APR was dead simple. (No RPM available, but not needed.)
Autoconf: I had a version of autoconf in
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,
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!
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.
It's not the depth of the water thats the problem. It's the current that kills you.