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.
Tell me what has Subversion got that CVS hasn't? (No this is not a flame, I'd like to know).
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).
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
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
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.
You could've hired me.
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!
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.
What?
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.
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
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
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!
Here's a list ...
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
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?
"There is no night so forlorn, no mood so bleak, that it cannot be infused with pleasure by tender meat..." - R.W. Apple
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.
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: /.ed, so I can't check, sorry)
- Berkeley DB, a particular version (this makes sense)
- Apache 2.x
- WebDAV
- Neon
and a bunch of other stuff, IIRC. (Their site is
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.
SCC works well for several purposes:
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.
What?
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
Ugh, how awful. One of the things I love about CVS is that it can run over ssh.
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.
A deep unwavering belief is a sure sign you're missing something...
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.
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.
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
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.
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.
It must be new, I checked quite awhile ago and it wasn't there.
What?
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.
If you're whacking it to Slashdot, you have larger problems than people watching you flog the dolphin ;)
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
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.