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."
CVS is weak at best with a long standing list of quirks, bugs and missing features. The current architecture and code base is in such state where many opt to not make the attempt at crowbar many of these features and fixes into CVS. In CVS, security is non existant, branching takes up a lot of unnecessary resources and quite a great deal of time, lacks meta data like directory revisioning along with various other usefull items, stores useless CVS data in the repository and has a tendancy towards being slow. The worst, inexcusable, flaw in CVS is the complete lack of atomic commits.
On the flip side, I do not suggest using Subversion for any critical project at this point since they are not feature complete for their first release and their bug list, frankly, scares me.
If something goes wrong during a CVS checkin, then all hell can break loose.
Sex - Find It
Directory handling springs to mind, as does renaming files. Atomic commits too. As well, there's also the fact that you often end up editing the modules files directly - an end-user should never have to care about a program's internal storage of meta-data.
Now, I haven't used Subversion so I am unable to make a comparison. I understand it handles directory versioning better, but I'm not aware of the rest of the points I made. The directory handling alone is a huge plus however, so it's a project whose announcements I'm following closely.
Cheers,
Ian
You could use the LastChangedDate or LastChangedRevision tags. This is taken from the manual:
LastChangedDate
The last time this file changed. Can also be abbreviated as Date. The keyword substitution of $LastChangedDate$ will look something like $LastChangedDate: 2002-07-22 21:42:37 -0700 (Mon, 22 Jul 2002) $.
LastChangedRevision
The last revision in which this file changed. Can be abbreviated as Rev. The keyword substitution of $LastChangedRevision will look something like $LastChangedRevision: 144 $.
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.
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
Aegis (http://aegis.sourceforge.net/) supports creation of "better" quality software by enforcing a process on the project
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
Sorry, it was basically a wording slip-up on my part (probably because of my cvs-thinking influence). I knew Subversion uses the global revision number that applies to the entire filesystem tree in that repository.
Without going into all the details of how I currently do things, another user, xlv, has already pointed out to me, the LastChangedRevision is what I was looking for.
I'm actually reading the docs at http://svnbook.red-bean.com/book.html to increase my understanding of Subversion right now.
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.
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=
From the docs, compare with CVS. Remember that many of the Subversion deveoplers are/were CVS developers..
* Real copies and renames. The Subversion repository doesn't use
RCS files at all; instead, it implements a 'virtual' versioned
filesystem that tracks tree-structures over time (described
below). Files *and* directories are versioned. At last, there
are real client-side `mv' and `cp' commands that behave just as
you think.
* Atomic commits. A commit either goes into the repository
completely, or not all.
* Advanced network layer. The Subversion network server is Apache,
and client and server speak WebDAV(2) to one another. (See the
'design' section below.)
* Faster network access. A binary diffing algorithm is used to
store and transmit deltas in *both* directions, regardless of
whether a file is of text or binary type.
* Filesystem "properties". Each file or directory has an invisible
hashtable attached. You can invent and store any arbitrary
key/value pairs you wish: owner, perms, icons, app-creator,
mime-type, personal notes, etc. This is a general-purpose feature
for users. Properties are versioned, just like file contents.
And some properties are auto-detected, like the mime-type of a
file (no more remembering to use the '-kb' switch!)
* Extensible and hackable. Subversion has no historical baggage; it
was designed and then implemented as a collection of shared C
libraries with well-defined APIs. This makes Subversion extremely
maintainable and usable by other applications and languages.
* Easy migration. The Subversion command-line client is very
similar to CVS; the development model is the same, so CVS users
should have little trouble making the switch. Development of a
'cvs2svn' repository converter is in progress.
* It's Free. Subversion is released under a Apache/BSD-style
open-source license.
Version control works fine across file renames; CVS simply doesn't make it obvious that a rename happened (the old file disappears, a new file with a clean log appears). The simple way of dealing with it is to add a comment to the new file "formerly known as".
If it really confuses you, it's easy to give people a shell script to do the remove/add, add a comment, and optionally, add a copy of the old log. Perhaps the CVS developers should do just that.
has some issues with binary files,
I dunno--they seem to get handled just fine. They aren't diffed, but so what? Perhaps the CVS frontend should finally detect binary files automatically--doing that wouldn't be hard.
the CVS code base has serious design issues.
Lots of widely used big C programs have "serious design issues", at least in some people's eyes. I've come to the conclusion that if it works reliably, it's best not to look under the hood. And CVS works reliably. I'd trust it over a well-designed but new codebase any day.
Although there is a definite place for the "If it ain't broke, why fix it?" philosophy, its also equally often a good time to remember there was nothing broken about the horse and cart. While CVS is a good stable system that has many times over proven its worth, we also have to recognise there _are_ features lacking and issues that if corrected, would allow for greater productivity. Such as the binary file handling. Binary support in Subversion looks to be a _LOT_ easier than in CVS. Currently CVS always transmits binary files in full. And CVS does have networking issues.File differences are sent in only one direction, from the client to server, but not the other way round. And because of CVS's codebase, which is very ugly (not surprising given its history of being layers of hacks), it becomes increasingly hard to add new features. In short, we've approached the stage with CVS where a complete overhaul and restart would be better longterm.
If you work on a local machine, you can use simple "urls" like file:///var/svn/myrepos/ instead of the http://server/svn/myrepos/, and the Subversion people are now working on new network layer, libsvn_ra_svn, which offers a new networking layer (svn://blahblah/).
:-)
A standalone subversion server is also in development, but I don't remember if it's scheduled for 1.0 or not. However, this is free software, if you feel like you need it, you can help developping it !
The point is, this is indeed a good remark, but not a showstopper. And the Apache2 svn server works just perfect for me !
theefer
actually, the next release of subversion will support a new repository access layer (called ra_svn, for lack of a better name), which uses a custom (but simple) tcp protocol that can easily be tunneled over ssh. it's pretty new, and might have some kinks we haven't found yet, but it passes all our regression tests so far.
"It does if you add it (or automate adding it with a simple cvs-rename script). However, it's not clear that that matters much."
Manually tinkering with the CVS metadata should never be necessary, especially for something so common as moving a file.
"Of course, it's included. The diffs will contain a deletion for the old file and an addition for the new file. That is exactly what should happen. I don't think "diff" even supports any other way of renaming."
That is exactly the problem: diff does not support any other way of renaming. In fact, diff does not support renaming at all; it supports only deletion and addition, which is not the same as renaming. With deletion and re-adding, the history of the new file does not indicate that it was moved from another location; it appears to have been spontaneously generated. You are still thinking in terms of diffs, and assuming that the limits of diffs are the limits of source code control. Diffs are the very architectural drawback of cvs; with subversion, you can get a history that indicates "this file was moved here, then there, then there, then this directory was created and that one deleted, etc." ALL of that is impossible with cvs, and all of it is quite common.
"Well, your message suggests to me that handling renaming any other way than the way CVS does may actually be worse."
It would be difficult to be worse; cvs does not even handle renaming at present, but only deletion and subsequent addition, which is not the same. The authors of the original cvs are the ones writing subversion, because they realize cvs's serious limitations in this regard. CVS also has limitations in other regards, like lacking atomic commits. This would be possible to implement in cvs, using diffs, but it would be very hacky.
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.