Slashdot Mirror
Multi-User Subversion
chromatic writes "Rafael Garcia-Suarez has just penned an article about adopting Subversion for multi-user projects. (He also has a previous article on Single-User Subversion). With the recent release of Subversion 0.16 (see the File sharing link), the successor to CVS looks very good."
Sorry, I'm not exactly a professional developer but:
Whats the advantage to killing the standard of CVS, that seems to work well today? I mean, are the features of this "Subversion" make it worth the switchover?
Actually I would like to know how this "subversion" compares to what Linus is using?
I really hope that building ancillary tools like nice clients (wincvs) and useful add-ons (bonsai) is easy enough to do, because that's really where the critical mass is wrt widespread adoption.
There aint no pancake so thin it doesn't have two sides.
If something goes wrong during a CVS checkin, then all hell can break loose.
Sex - Find It
bah automatically violates all copyright laws, anyone who downloads this software is violating internation al copyright law and the dmca.
Ignore the "p2p is theft" trolls, they're just uninformed
The fundamental design of CVS is flawed, and this leads to anomolous behavior. Becase the problem with CVS is in its design, not its current implementation, a re-design and corresponding re-write is reqiured.
For example, CVS stores its repository in a series of diffs in a directory structure, and the directory structure parallels the development tree. The difficulty is, directories in the cvs backend are therefore not versioned! Thus, moving files around, and re-working the tree, are not handled correctly in cvs. In subversion, the entire repository (dirs, files, and all) is stored as a single coherent revision; a subversion repository is an array of coherent tree/file groupings. As such, correct handling of directories occurs automatically. Also, atomic commits (something cvs lacks) are handled much more easily in this model.
Let me also say that the design of subversion is absolutely excellent. The design is properly decoupled and properly abstracted. Architecturally, it is greatly superior to cvs, and substantially superior to several commercial alternatives. I would imagine that the low-end source control products (PVCS, SourceSafe) will have significant difficulty staying alive once Subversion is widely deployed and tested.
One thing I like to do is put in the CVS $Revision$ substition variable in each of my text-based project files. I use them to help me know which version I've got on my live site...for if I've made bugfixes to that branch, etc.
If there aren't any changes to the file in my new tagged & branched release, that $Revision$ variable will stay the same between releases. This is irrelvent for all my other files that aren't web-related, but the ones that are can remain cached in a user's browser as long as there haven't been changes to the file (this is especially helpful if I have large javascript library files that would otherwise slow down loadtimes a lot).
However, I don't see how I can do this using Subversion. It looks like the version for all project files is incremented everytime a single file checked-in.
Is there an alternative or better technique than what I'm doing by using Subversion? I like its advantages over CVS and would like to experiment with it more!
That sounds like exactly what I wanted!
Hmm...I better go read that manual. I thought I had gone over everything already. It was a while ago during the whole Linux kernel and Bitkeeper licensing "debate", but I probably skimmed it too fast as well.
Thanks.
Of course, no discussion of CVS's strengths and weaknesses vs. Subversion would be complete without mention of the third contender, arch. Link 1, Link 2.
I hereby adopt subversion 0.16.
I am now Dimwit 22.16.
(Subversion - sub-version...get it? Ha ha? Ahhh...nobody has a sense of humor these days...)
...but it's being eaten...by some...Linux or something...
If you're a coder, and have never used CVS, try it. It's absolutely lovely. "Oh, introduced a bug there...let's just diff against a known good version." "Oh, it looks like *Bob* was the one to commit that broken code." "Why did I add *that* code? Let me check my CVS log..."
Yeah, there are probably things about CVS that could be better. But if you've never used it, and aren't already using a competitor, it's really good.
May we never see th
All it did to me was close IE.
matguy(.com)
Aegis (http://aegis.sourceforge.net/) supports creation of "better" quality software by enforcing a process on the project
The only problem I have with subversion is its dependences on apache which just gets in the way in a local project unlike cvs which can be used over rsh/ssh, cvsserver, and locally. The other problem with apache is that they use the HEAD of httpd and apr as their base which is wrong for use with Darwin(Mac OS X). Also apache is big and is too modular for a project like subversion.
I've been moving all of my CVS development over to Subversion over the past few months, including a couple development servers at my company.
Since Subversion is now in Debian unstable, it's really easy to install. Compiling from source is a bit of a hassle due to all the dependencies, especially on the apache2 libs.
So far, I've not had a bad experience. No data loss or anything. And I'm very, very happy that I can finally get rid of pserver.
Subversion impressed our company developers by its speed (subjectively, considerably faster than CVS for comparable operations) and its user-friendlyness. It's the details, stuff like automatic detection of binary files, that makes life for the dev people easier.
For the admin, the fact that it runs via apache2 makes your life much easier, especially when it comes to firewalling and access control (user and passwords, etc.) - in a corporate network, you could easily plug it right unto your LDAP server for authentication, for example.
Two things are holding Subversion back right now, IMHO:
a) lack of a wincvs/tkcvs equivalent. Rapidsvn is making progress, but it's still very much alpha.
b) a couple things still missing, like understanding symlinks.
Assorted stuff I do sometimes: Lemuria.org
see the File sharing link directly from the freekin frontpage. This was meant for humor, but obviously the moderation has no sense of humor. Off topic was a bogus moderation though.
Ignore the "p2p is theft" trolls, they're just uninformed
And what about migrating from CVS/RCS? Are there tools to do it? It would be nice, if not mandatory, for a lot of big projects out there. Regards
Check out Aegis - http://aegis.sourceforge.net. It's better than Subversion. It's older than Subversion. It's more stable than Subversion. It has atomic multi-file commits. Branching to any depth. Multi-user support. Distributed support. Applying change sets to multiple repositories. And much, much more.
aegis.sourceforge.net
Does anyone have any experience with integrating Subversion with, say, NetBeans? Does it work as good as the CVS support in NetBeans?
:-)
I'll probably try it anyway, I'm just lazy.
Being bitter is drinking poison and hoping someone else will die
Damn you. That thread got me to download subversion source and read it -
1 03 402696209262&w=2
mistake I won't repeat any time soon. I've spent several months wading
through fairly disgusting code - block device drivers are not pretty,
ditto for devfs. I had more than once found myself grabbing Lovecraft
to read something that would be less nightmare-inducing. But _THAT_ takes
the fscking cake - I don't _care_ what Larry (or anybody else for that
matter) does to people who had excreted that code. No, wait - I _do_ care.
I want video of the... event.
I don't use BK, but you can be damn sure that I won't touch SVN. Ever.
Short and concise as ever.
http://marc.theaimsgroup.com/?l=linux-kernel&m=
Generally, Subversion's interface to a particular feature is similar to CVS's, except where there's a compelling reason to do otherwise.
How about this for a compelling reason; CVS's interface is HORRENDOUS!
Look, CVS has fantastic features, to be sure. But it has a horrible interface that's far more complex than it needs to be. I haven't even found a GUI front-end that can make it easy to use.
It's great to have powerful features, but not everyone needs all that power. 9 times out of 10, all I need is simple check-in and check-out with revision control. I don't need encryption. I don't need a million options for checking in and checking out.
I just find all this other stuff gets in the way. I'm a firm believe that if you want to use software at it's simplest levels, it should be simple to use. As you get to more advanced features, it's okay for it to get more difficult to use. But to make it difficult to do the most basic things just doesn't make sense.
I don't mean to slam CVS, but I'd just really like to see a simple to use alternative to it. Too many times I've gotten lost with CVS wondering exactly what the hell I had done.
Damn you. That thread got me to download subversion source and read it - mistake I won't repeat any time soon. I've spent several months wading through fairly disgusting code - block device drivers are not pretty, ditto for devfs. I had more than once found myself grabbing Lovecraft to read something that would be less nightmare-inducing. But _THAT_ takes the fscking cake - I don't _care_ what Larry (or anybody else for that matter) does to people who had excreted that code. No, wait - I _do_ care. I want video of the... event. I don't use BK, but you can be damn sure that I won't touch SVN. Ever.
found on The Linux Kernel Mailing-List
In comparison, CVS over ssh is secure and works pretty much everywhere. Many machines don't need to run a web server, let alone Apache 2, while ssh pretty much runs everywhere.
Subversion does look somewhat better and cleaner than CVS. But there are lots of add-on tools for CVS that will need to get ported (GUIs, servers, web interfaces, IDE integration, etc.). Just the retraining required to get people to use it in a multi-user environment is pretty daunting--CVS is used by many people who are not primarily developers, and the switch wouldn't be easy for them.
It's been years since we have had any signficant problems with CVS; it seems to be just ticking along, doing its thing. So, I'm not convinced switching to subversion would be enough an advantage to outweigh the risks and retraining costs associated with it. I think it would take a number of large and very visible open source development projects switching to Subversion to give me enough confidence in it to try it.
I wasn't going to bother, but the previous comment mentioning arch has been modded up to 4, so I'll speak a tiny bit of my peace.
... well, just follow the dev list closely.
SVN is a huge and complex system that aims, for its 1.0 release, to be just a tiny bit more featureful than CVS. There's quite a large number of bugs. The complexity for repository administrators is pretty high. The developers are willfully postponing consideration of a lot of deep issues in revision control. If you follow the dev list closely
arch is a tiny, simple system that aims, for its 1.0 release, to be way more featureful than CVS. Although I don't think its ready for deployment in large-scale situations, early adopters tell me that they enjoy using it. arch, unlike svn, is very well positioned to compete (with just a bit more development) with BitKeeper, ClearCase, and others. arch can do a hell of a lot for the commercial free software world with just a bit of investment.
And, I don't know how you should interpret this, but svn has a handful of paid developers -- arch has none and, in fact, I'm literally days away from homelessness.
Go figure.
improving Arch instead of blathering about it people might give a shit. I mean this in the nicest possible way, of course. God knows you've got the time - over 100 lengthy posts to the GCC list in the last week alone.
Sure it might be a strong sucessor, but if its stable series will not configure/compile on my box then it's useless. (it has issues when you tell it to compile without apache).
:-) )
If you haven't already, please report this to the developers. (Or fix it yourself
I've had no problems building subversion here and virtually all my builds are without apache.
Multi-user subversion?!
Isn't that a punishable offense now?
No, Beowulf clusters can't imagine in Soviet Russia.
I'd love to use SVN. I once tried to set it up on my own system (long ago, when it was much more difficult than it is now).
Then I decided that if I wanted to get other people involved in my project, using SourceForge would be simpler for me and them. And SF uses CVS.
If SF offered an SVN option (does it? will it?), I might move to that. I don't much like CVS for normal development (refactoring's a bitch), but the alternative is to host all the stuff that SF does on my own. I'm a developer, not a sysadmin; I don't have time for that.
It is free
CVS operates on a per-file model. Each file has its own history, branches, and so on. Operations on a set of files actually visit each file, perform the operation, and move on.
This leads to the following problems:
Creating a branch or a tag visits (and writes on) every file in the source tree, so it takes a long time. For example, the gcc folks would like to create periodic snapshots of their source tree and publish the snapshots. One step in doing this is tagging all the files. Well, creating that tag writes information into every source file and takes HOURS.
Renaming a file is not supported. All the history information in CVS is associated with "foo.c". If you want to rename "foo.c" to "bar.c", you actually have to create bar.c and then delete foo.c. This loses all the history associated with the old foo.c.
Directories are even worse. There is no way to delete a directory in the CVS repository (that's what all the "prune on checkout" kludgery is for, to delete empty directories in the client work area that should not even exist in the first place).
When I edit source, I often edit more than one file. I might edit 10 files in 5 separate directories. CVS has no notion that my changes are one "unit of activity". The GNU project uses ChangeLog files, which manually tie the 10 changes together and actually work very well. But it would be even better if CVS knew that when I committed 10 files, it's all part of one changeset, not 10 separate changes. That makes it a lot easier to backport patches from development branches to stable branches, to figure out what some other guy did (hmmm he changed foo.h, I wonder what went along with that change?)
These are all well-known problems to people who use CVS a lot. Newer source control systems (bitkeeper, subverrion, arch) all have the idea of changesets in some form or other, and all have better ways of implementing whole-tree operatings like tagging and branching.
These are just the "data model" problems. The standard CVS server has other implementation problems -- that is, problems that could be fixed just by improving the server, without changing the millions of cvs clients in the world. One big problem is that CVS needs write access to the files, even for read-only operations such as anonymous checkout, and does excessive disk I/O, even for read-only operations. This is particularly annoying because CVS doesn't guarantee checkout consistency across a whole tree anyways, but only a single directory! This is no big deal in a departmental cluster but it becomes a serious issue for public open source servers that are trying to scale up to serve the whole world and do it with limited resources.
If I use the start of the mailing list archives as a guide, I would say both are about the same age (around April 2000). Both are still in alpha (check Subversion's status).
Personally, I would like a better comparison of these two.
In any revision control system, whenever you commit a file-change you are affecting the entire repository. Even if you only modify a single file, you're still causing the state of the repository as a whole to shift. Therefore, it's only logical that revision numbers be tracked at the highest possible level.
As an analogy, suppose you kept a record of everytime you changed something in your car. Would you keep separate records for each part, or would you keep a single set for the entire vehicle? Most people would probably go with the latter as it makes the most sense. Regardless of what you change, whether you're replacing a single bolt or swapping out the entire engine, you're still making a modification to the car.
Subversion is indeed already a giant step better than CVS in all the areas where CVS was painful, while having a good migration path. Arch, OpenCM, and PRCS2 could be in the running, and Arch has that multi-repository support going for it. But I'd say Subversion is the best thing going as of right now.
I have a listing of all known SCM software for Linux at http://linuxmafia.com/~rick/linux-info/scm.html, in case it will help.
Rick Moen
rick@linuxmafia.com
Case in point: Quite often, during code reviews or programming sessions, I come across bugs or bad programming methods that exemplify a certain fundamental lack of experience or understanding on part of the author. Using cvs annotate I can determine exactly who wrote the line(s) in question, discuss the problem with the culprit and, if I do my job right, hopefully ensure that the mistake is not repeated. Without the annotation feature, I would have to ask each team member whether they wrote the code in question. Too often it happens that they don't remember. We have had some major directory reorganization the last few months, and at one point all of our files lost their history simply because of a single directory renaming operation.
The remove/add renaming trick damages the projects' collective memory. You end up with bits of the past that are simply missing.