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."

Comments

Subversion vs CVS

[Slashdotess]

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?

Re:Subversion vs CVS

[Anonymous Coward]

You have never tried to move a directory in a CVS repository, have you?

obKarmaWhoring: http://subversion.tigris.org/

Re:Subversion vs CVS

[Cebu]

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.

Re:Subversion vs CVS

[bdash]

A good discussion of this was in Linux Journal recently.

Briefly, CVS lacks version control across file renames, has some issues with binary files, and the CVS code base has serious design issues.

Re:Subversion vs CVS

[mccalli]

Well, I am a professional developer, and I have to say that CVS amongst the 'worst' of the source control systems I've used. That sounds incredibly critical, but I really don't mean it in a disrespectful sense. A need for a freely available, open source control system was there, and CVS filled and continues to fill it well. Better than SCCS and RCS ever did. Despite that however, its functionality is a little lacking compared to most commercial rivals.

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

Re:Subversion vs CVS

[Anonymous Coward]

> but I'm not aware of the rest of the points I made

I have that trouble all the time.

Fortunately, you can get a quick reminder here...

http://developers.slashdot.org/comments.pl?sid=4 86 63&cid=4935145

Re:Subversion vs CVS

[bzzzt]

Even seen the CVS bug list? :)

Re:Subversion vs CVS

[noselasd]

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.

Re:Subversion vs CVS

[g4dget]

CVS lacks version control across file renames

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.

Re:Subversion vs CVS

[syphoon]

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.

Re:Subversion vs CVS

[Anonymous Coward]

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".

Implementing "move" as "remove ; add" works, but it is not very convenient. The history of the file is now split into two: the part before the move and the part after. In "blame annotation" all lines from before the move are shown as originating from a single revision.

I dunno--they seem to get handled just fine. They aren't diffed, but so what?

Large binary files are a real problem to CVS. At work we had 3 revisions of a 60MB file. When doing an export or update, the CVS server process would hang up, or at least progress so slowly is wasn't noticable anymore.

There is another issue that is indirectly linked to binary files. Some other configuration management systems have options to prevent two people editing the same file, CVS does not. Two people can edit the same source file and afterwards their changes are merged, which works well most of the time. However, if two people edit the same binary file, there is no way to automatically merge the results. So one of them has to redo all the changes.

Perhaps the CVS frontend should finally detect binary files automatically--doing that wouldn't be hard.

A decent "cvswrappers" configuration file in your CVSROOT will take care of this. However, the default "cvswrappers" file is empty.

I use CVS at work and at home. I like it: it's free, it's stable, it performs reasonably well and it gets the job done. But it is nowhere near perfect.

Re:Subversion vs CVS

[BrightCandle]

Well, I am a professional developer, and I have to say that CVS amongst the 'worst' of the source control systems I've used.

As am I and I have to agree. CVS is impossible to decouple from Unix properly let alone it's glaring security problems.

For a long time I've had in my future projects list a better source control system. I noticed this project a few months back and I've not had any issues with it yet. The fact that it's self serving should give people some idea of just how confident the developers are and I have to say it's well placed.

Eventually everyone will be using this, it's just easier.

MOD PARENT UP

[Anonymous Coward]

Although I disagree with the author of the article, I think he makes a valid point that CVS was first.

Re:Subversion vs CVS-Alternatives?

[Anonymous Coward]

Actually I would like to know how this "subversion" compares to what Linus is using?

sounds cool

[farnsworth]

subversion sounds like a really cool tool. I've been following it for about a year now. it has some great advantages over cvs, such as multi-file atomicity, and good support for refactoring.

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.

Re:sounds cool

[reaper20]

Ugh, never call wincvs a nice client.

tortoise cvs if you're ever in a win environment.

Re:sounds cool

[farnsworth]

I agree that tortoise has some really great features. but it breaks down badly if you have more that a few dozen files per directory. I've never looked at the tortoise code, but wincvs performance is way better, even in 'flat mode'.

I don't use wincvs too much, but it's really easy to train people on, and despite its quirks, it's is pretty nice.

Re:sounds cool

[stefanlasiewski]

If you're interested in clients, check out the http://scm.tigris.org/ pages: There's a GTK and a cross-platform GUI in the works (And I've seen a few other GUIs on elsewhere (sourceforge?)

Re:sounds cool

[joib]

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.


Most of the subversion functionality is actually in a library, which makes it a lot easier and more robust to build gui clients and such for subversion. CVS, by comparison, is only accessed through the command-line client, so cvs gui clients have to execute the cvs binary and then parse the output, which as you certainly can imagine, is cumbersome.

Re:sounds cool

[dubl-u]

CVS, by comparison, is only accessed through the command-line client, so cvs gui clients have to execute the cvs binary and then parse the output, which as you certainly can imagine, is cumbersome.

Anybody who doubts this should try reading the source code to cvs2cl. All it does is build a CHANGELOG file based on the developer comments at checkin, so it should be pretty straightforward, right?

Not nearly. I wanted to make some other CVS reports; when I looked at all the rigamarole that cvs2cl has to go through, I just gave up. With enough time my brain could have handled it, but my stomach never would have.

i clicked the link.......

[Anonymous Coward]

....and the image didn't load.... do i consider myself lucky? ;)

Re:i clicked the link.......

[Anonymous Coward]

yes... for using DECENT web browsers, like Mozilla or Konquerer, and not USELESS PILES OF SHIT like Internet Explorer... I can't believe anyone would use crap like that! If I used IE, every day I'd have thousands of pop-ups and malicious Active X attacks to fend off, all because Microsoft think people WANT the web to destroy my computer! Thank goodness I use Linux!

Atomic checkins are a must...

[dagg]

Something that is great about Subversion is that it has atomic checkins. That means if something goes wrong while you are checking in a file, then your checkin is rolled back. That is super-handy, and brings it up to par with Perforce (a commercial revision control system that I've used in the past).

If something goes wrong during a CVS checkin, then all hell can break loose.

Re:Atomic checkins are a must...

[stefanlasiewski]

That is super-handy, and brings it up to par with Perforce

Wait, I thought Perforce was heavily based on CVS? Was I wrong?

Re:Atomic checkins are a must...

[dagg]

I'm not sure where you got that idea. There is no connection, whatsoever, to my knowledge. Here is a comparison page provided by the Perforce folks: comparison chart.

Re:Atomic checkins are a must...

[wscott]

I think what he is remembering is that Perforce stores its file data in RCS files just like CVS. But that doesn't prevent atomic commits. Since they have a central server they can easily block other users during the commit and do a rollback if something fails.

Re:Atomic checkins are a must...

[Krellan]

Another use of atomic checkins is checking in more than one file at a time, especially when checking in two files whose changes depend on each other. In my experience at several CVS shops, the build sometimes breaks simply because of unfortunate timing: checking out the tree while someone else is in the middle of checking in a series of files. Most shops deal with this manually, by having certain rules, such as no checkins allowed at all during a certain hour of the night.

If there was a way in CVS to begin a transaction, then do multiple checkins, then commit/rollback that transaction atomically, that would be wonderful. It would be impossible for one person to check out someone else's partial checkin.

If Subversion is getting this feature, or even has this already, it will be one of the best "selling points" to replace CVS!

Re:Atomic checkins are a must...

[roskakori]

[atomic checkins are] super-handy, and brings it up to par with Perforce

while perforce is not open source, they still grant a free license for 2 clients. this is enough for toying with my g4 and ibook. additionally, all the manuals are online, and so are ports for many different systems. there are plugins for many ides, and a web-gui based on html-forms. what i like the most is the relative ease of use of all parts involved.

until someone comes up with a stable and usable open-source tool, perforce might serve any home-user's needs.

Re:Atomic checkins are a must...

[Daniel Phillips]

And it has directory versioning, another must. Plus a whole lot of very-nices. For example, the version history is stored in the form of exact binary diffs (xdeltas) whereas cvs uses rcs, which uses a text diff, which is horribly, unspeakably crude, not to mention inefficient in both time and space. As a bonus, Subversion doesn't have to do anything special to handle binary files.

Re:Atomic checkins are a must...

[styxlord]

Using CVS with a build process is easy. The developer that wants to trigger a build does an update, commits all of their changes, resolves and commits any conflicts, tags the source and then triggers the build using the tag. Any subsequent commits, including partial ones are ommited from the build and as an added bonus you can build any previous build from the source.

Re:Atomic checkins are a must...

[Ed Avis]

Why does it matter what kind of diff the version control system uses internally - 'crude' or otherwise? You shouldn't need to care about such details.

The disk space argument is valid I suppose. But what would _really_ save disk space is a way to compress the source repository, either everything or just the older revisions. My $CVSROOT directory is huge and most of that is stuff I will probably never need to access.

Or if space is really tight, a way to selectively forget about older revisions. I have a bunch of very large text files under version control, in fact they are word lists for ispell(1) and similar programs. An operation like sorting the list into alphabetical order generates a huge diff, but the log message is entirely sufficient to describe the change. I'd like to cut out some of the version history so that only log messages are preserved for older versions - you wouldn't be able to check them out, but I wouldn't want to anyway. So far the only way I can see to do this is to hack the RCS files by hand.

Re:Atomic checkins are a must...

[Ed Avis]

You can get atomic checkins with CVS: just lock the repository before making the commit and unlock it afterwards. Karl Fogel's book explains somewhere how to do this. You don't get rollback though.

Re:Atomic checkins are a must...

[dagg]

Testing by responding to my own post.

Please ignore.

--sex

filesharing?

[SuperDuG]

bah automatically violates all copyright laws, anyone who downloads this software is violating internation al copyright law and the dmca.

Oh damn, for a minute I thought . . .

[kfg]

this had something to do with CPU Wars.

KFG

Subversion is far better than CVS

[cartman]

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.

Re:Subversion is far better than CVS

[7-Vodka]

well I just hope it has all the goodies on Linus' xmas list.

Re:Subversion is far better than CVS

[g4dget]

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.

To rename files in CVS, you remove the old file and add it as a new file. The semantics of this are well-defined, and you will get a consistent view of the tree no matter which version you check out. It's simplistic, but it works. The one thing that is a bit clunky is the fact that old, empty directories hang around, but that really isn't a big deal in practice.

Re:Subversion is far better than CVS

[Majix]

To rename files in CVS, you remove the old file and add it as a new file.

But this new file does not have the history of the old file, you can not check out last weeks version of it and it is not included in diffs of changes that spanned multiple files. Deleting and adding, though it may be well-defined, is also a really ugly and non-intuitive way of doing it.

CVS has had its time, there's no reason to defend it any longer. CVS is being maintained, but it is not really in development anymore. I'm also pretty sure that I read somewhere that a significant portion of the CVS developers are in fact working on Subversion these days.

Subversion will replace CVS, no question about it, it's only a matter of time.

Re:Subversion is far better than CVS

[g4dget]

But this new file does not have the history of the old file,

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.

you can not check out last weeks version of it

Sure you can: if you ask for last weeks version of the software, it will contain the file under the old name. If you ask (somehow) for the individual file, CVS will tell you that it didn't exist at that time, which is correct and consistent. It would be inconsistent if I got a week old version of "newname.c" if "newname.c" didn't exist at that time. I do hope Subversion doesn't do that.

and it is not included in diffs of changes that spanned multiple files.

Huh? 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.

Deleting and adding, though it may be well-defined, is also a really ugly and non-intuitive way of doing it.

Well, your message suggests to me that handling renaming any other way than the way CVS does may actually be worse.

Re:Subversion is far better than CVS

[JLyle]

It does [have the history of the old file] if you add it (or automate adding it with a simple cvs-rename script).

No. If you use cvs rm to remove the file under its old name, and then re-add it under a new name using cvs add, the new file does not include the revision history of the old file. It starts over at revision 1.

Re:Subversion is far better than CVS

[dubl-u]

But this new file does not have the history of the old file,

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.

Doesn't matter much to whom? To you? Then fine, you can keep using CVS; we'll tell the SCCS Police to make an exception for you.

Or are you saying that cross-rename history tracking doesn't matter for all developer everywhere? In which case, I'd love to hear more about how you checked with them. I must have been out when you called.

Re:Subversion is far better than CVS

[cartman]

"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.

$Revision$

[aok]

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!

Re:$Revision$

[xlv]

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 $.

Re:$Revision$

[Cebu]

What do you mean by "the version for all the project files is incremented everytime a single file [is] checked-in"? Subversion increments of the global revision number everytime a checkin occurs, much like many other source control systems such as Perforce, but versioning is handled by the user by whatever means they choose (branch from main line with tags for minor revisions would be one way). However, you can always obtain the last revision number of a given file which is probably what you're interested in.

Re:$Revision$

[aok]

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.

Re:$Revision$

[Grayraven]

You also have to set the svn:keywords property, like this:
svn propset svn:keywords "lastchangeddate lastchangedrevision" [file]

Strong sucessor?

[Anonymous Coward]

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).

Re:Strong sucessor?

[RupW]

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.

Thanks!

[aok]

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.

Multi-User Subversion...

[C.Maggard]

Microsoft immediately came to mind.

arch

[bedessen]

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.

Re:arch

[Renegade Lisp]

Tom Lord, the author of arch, has an interesting comparison of arch vs. Subversion and CVS.

What's really new about arch is that it makes version control decentralized, rather than merely distributed, as CVS and Subversion do. In arch, any branch, any developer's private work area can be regarded as a repository of its own, with a global name space for developers, repositories, and branches, to manage this.

With CVS and Subversion, the repository is still a centralized entity. Compared to arch, these systems are still at a similar conceptual level, while arch adds something that is really new.

Re:arch

[jonabbey]

Sounds a bit like Bitkeeper, the commercial, decentralized source code control system being used by Linus and a bunch of the Linux kernel hackers these days.

Re:arch

[hayriye]

it lacks the feature that made Linus decide to move his tree to bitkeeper. That's more than one developer can create a separate tree to work on some feature, then commit their tree to the main tree.

Okay, I will...

[Dimwit]

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...)

Re:Okay, I will...

[Suicide]

You forgot to say, "Imagine a beowulf cluster of these...".

Re:Okay, I will...

[Ari Rahikkala]

However, I subvert your development team from under you. Good luck trying to release a new version without any developers! (truly, few people if any have a sense of humour nowadays)

Re:Don't use IE dumbshits

[jmcfarlane]

*!@$&%#BSD is dead --> not

Re:Extra Info

[Anonymous Coward]

At least it's nice to know that the new memory I installed today works wonderfully. ;-)

CVS still awfully nice

[0x0d0a]

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.

Re:CVS still awfully nice

[Cuthalion]

cvs is way better than no version control. agreed. hell, PVCS and Source Offsite (the two worst version control systems I've ever used) are still way better than no version control.

Public service announcement

If you're in windows and trying CVS, check out tortoise

Re:CVS still awfully nice

[Anonymous Coward]

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.

That's what middle-school geeks used to say about BASIC.

Re:CVS still awfully nice

[dubl-u]

cvs is way better than no version control. agreed. hell, PVCS and Source Offsite (the two worst version control systems I've ever used) are still way better than no version control.

On a project with more than two developers, quitting to work the fryer at McDonald's is way better than no version control.

Re:Don't use IE dumbshits

[matguy]

All it did to me was close IE.

Aegis is another one

[Anonymous Coward]

Aegis (http://aegis.sourceforge.net/) supports creation of "better" quality software by enforcing a process on the project

Re:Aegis is another one

[__past__]

Looks interesting, however there are some things that bother me:

• It seems to require some failing tests that are to be fixed before you can create a development branch. How does this mix with refactoring? Do you have to invent a test for "This piece of code should be more elegant", or what?
• Is it possible to integrate the mandatory testing with an existing testing framework like one of the xUnits? Writing a shell script for each test case seems to be stupid.
• How about IDE integration? An Emacs mode?
• In general, what if I don't like something about the process it wants to enforce? Is it flexible enough to be adapted to local policy? Is it really a good idea to couple revision management and workflow? (It surely is not the "Unix way", which it like to integrate well with)

Re:Aegis is another one

[catenos]

What turned me away from Aegis is the fact that you have to adapt a policy at all. Aegis sounds great if you want to enforce a process.

But if you are fine to do without a rule-based process (maybe you have a small team, or very disciplined developers, or whatever), Aegis looks as if it brings a lot of unnecessary load with it.

Aegis is a source management system (and enforces it), while I only want a revision control system.

Re:Aegis is another one

[Adam J. Richter]

Do you have to invent a test for "This piece of code should be more elegant", or what?

I haven't actually used Aegis, but I assume that since the submitter also submits a test case, the submitter could "invent a test" as you put it that roughly corresponded to the way the new code is more "elegant."

I don't know if Aegis has this, but I'd like to see "benchmarks" in addition to "test cases." A test case basically either passes or fails, but a benchmark would return a score, so one could then submit a change that did not break anything but resulted in smaller line count, fewer branches, smaller object size, faster exeution, whatever without breaking other test cases or worsening other benchmarks. You'd probably also need to define a utility function that would combine benchmark scores to determine which combination was better, and I expect people would frequently submit changes or even branches to that utility function as their thinking evolved on how they'd like to optimize various trade-offs.

Re:Aegis is another one

[GooberToo]

Actually, as I understand it, that's not entirely true. While Aegis does have support for "a process", it is not mandatory. Rather, steps can be skipped and ignored. Furthermore, you can elect to adopt only the portions of the process that you like (test cases, etc). That means you only have to use as much as the process as you desire or none at all. In other words, it allows for a process framework to be used where developer supplied content fills in the framework or you can have null steps for each part of that framework leaving you with only the toolset behind.

Long story short, I believe that you've been misinformed. Feel free to correct as need.

Re:Aegis is another one

[catenos]

Well, could be that it is better by now.

But when I tried it (first quarter this year), I got too frustrated with setting up. If there is an easy way to avoid the part about enforcement, I missed it.

Maybe the problem is only that the documentation is too centric about that and ignores that some people would try Aegis for other reasons. Maybe I just was too unpatient.

But in the end, I dropped arch, because I got the impression that "skipping and ignoring" the steps got too burdensome. Probably this is, because Aegis emphasis too much (for my needs) to be more than a revision control system.

Re:Aegis is another one

[Ed Avis]

In an ideal world I would want to run the whole test suite before each checkin. (Whether or not I was using Aegis or some other version control system). But running a complete set of tests involves doing a complete build, perhaps even more than one build, and it would take far too long to wait for tests to run before your changes are checked in.

It would be great to have some kind of automated testing system that watches the checkins and runs tests 24 hours a day. Instead of running the test suite for every single checkin, it picks the current head revision of the project, tags it, and runs the tests. If they all pass then this revision is marked as the 'last known good' - there may have been other checkins in the meantime. Then repeat with the current head revision.

If a test fails, then it might not be immediately possible to work out what change set was responsible. There might have been a whole load of stuff committed between the last known good version and the version currently being tested. But the testing tool can work forwards from the good revision one change set at a time to find the guilty party, and send them mail about the problem. Or to be a bit quicker, use binary search to find the point where one of the tests broke.

only problem with subversion

[norwoodites]

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.

Re:only problem with subversion

[velco]

The only problem I have with subversion is its dependences on apache which just gets in the way in a local project

Do your homework first. You don't need apache for local projects.

~velco

Re:only problem with subversion

[Anonymous Coward]

RTFA (the previous one)

Re:only problem with subversion

[Anonymous Coward]

I think he meant local to a group, not local to exactly one computer. Subversion does not work on anything that isn't all on one machine, unless you have the latest CVS version of Apache. That includes networked file systems; i.e. the subversion repository can't be on NFS, AFS, Coda, etc. Lacking ssh support, and not using a standard apache without addition modules is a huge problem for subversion, but they'll never admit it.

Re:only problem with subversion

[Garrett Rooney]

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.

Re:only problem with subversion

[norwoodites]

You still have to compile subversion with apache though. CVS is a whole package while subversion requires a big extern project to compile it.

Re:only problem with subversion

[norwoodites]

Will support not compiling with apache support because apache is too big for my taste.

Re:only problem with subversion

[velco]

You still have to compile subversion with apache though. CVS is a whole package while subversion requires a big extern project to compile it.

This is not true. I have compiled subversion a number of times - it doesn't need the apache web server.

~velco

Re:only problem with subversion

[velco]

I think he meant local to a group, not local to exactly one computer.

I think he didn't.

Subversion does not work on anything that isn't all on one machine, unless you have the latest CVS version of Apache.

I think you're trolling and spreading FUD.

This is trivially not true - my version of subversion works together with some debian build of apache2, which is with absolute certainty older than 2002-12-21's version of the Apache's CVS.

Subversion uses CVS versions of Apache Portable Runtime - but this is not Apache.

And that makes a perfect sense for an alpha stage software.

That includes networked file systems; i.e. the subversion repository can't be on NFS, AFS, Coda,
etc.

What's you point ? Is this a requirement for a version control system ? Do other version control systems' repositories can be on NFS, AFS, etc. and why a SVN repository can't be ?

Lacking ssh support, and not using a standard apache without addition modules is a huge problem for subversion, but they'll never admit it.

I do not think this is problem _at all_. The subversion filesystem interface is abstracted and can (and in fact has) have many different implementations. One of the existing implementations uses Berkeley DB, another one uses WEBDAV (thus it can communicate with ANY WEBDAV server, NOT only Apache). One CAN provide SSH based implementation, too, as well as a SSL, RPC or completely custom one. So, instead of whining, you can implement SSH support if you need it. As for me, apache+SSL provide enough authentication/security.

It is just that SVN developers have other things to do than implementing zillion versions of libsvn_fs. They have covered the local case with Berkeley DB and the remote case with WebDAV + Apache + Berkeley DB - this should be enough for start.

~velco

some experiences

[Tom]

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.

Re:some experiences

[MarkoNo5]

Installing it is indeed very easy if you want to use unencrypted http. However, I'm having trouble setting up apache to use https. I have symlinked ssl.conf and ssl.load in /etc/apache2/mods-enabled, I have made a certificate and private key using the SSL-Certificates howto. I've put everything from the example ssl.conf file from apache2 in httpd.conf and modified the location of the key and certificate. Apache2 still doesn't accept any https connections (with or without the virtual host in the config file). When I enable the SSL engine ("SSLEngine on"), apache2 doesn't even start up, nor does it give any error message. When setting up a secure subversion server, I can't imagine that different people do it in a completely different way, so why isn't this documented properly ?

Re:some experiences

[Daniel Phillips]

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.

Oh yes, and the command syntax is suddenly sensible. For example, to check out subversion using subversion:

svn co http://svn.collab.net/repos/svn/trunk subversion

No CVSROOT, no -dgwana:gwana:gwana, no legacy silliness.

Off Topic??

[SuperDuG]

What the hell?

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.

Re:Off Topic??

[Anonymous Coward]

Stop whining about the moderation like a little pussy. My life is going to end, I've been moderated down! Waaaah...

Hurray

[TTimo]

Yay for SVN. Great project, great developers, and already a worthy replacement for old CVS.

Migration?

[badansible]

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

Re:Migration?

[LarsWestergren]

Yes, try reading the FAQ.

http://subversion.tigris.org/project_faq.html#cv s2 svn.

So far, its "only" a Python script. Very much in beta, the usual warnings apply, but they claim it's working ok.

As an example, the whole first
year of Subversion's own history was converted from CVS into a
3000+ revision svn repository. It took about 30 minutes.

http://svn.collab.net/repos/svn/trunk/tools/cvs2 sv n/README

Re:Migration?

[portnoy]

I've used this tool, and it does indeed work fine. But the showstopper for me is its inability to merge branches over. I would probably have moved our lab's repository over to subversion already if I didn't have to worry about losing all of the commits on the branches.

Aegis aegis aegis aegis aegis!

[Anonymous Coward]

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.

Re:Aegis aegis aegis aegis aegis!

[Dominic_Mazzoni]

Aegis sounds like a nice system, but it doesn't even run on Windows, nor did it ever run on Mac OS 8/9. CVS runs on everything, and Subversion is designed to be extremely portable, too. Sorry, but that's a critical requirement of a lot of developers - even open-source developers, because lots of us want our open-source programs running on as many platforms as possible.

Aegis

[saska]

aegis.sourceforge.net

Sounds good

[LarsWestergren]

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. :-)

Re:Sounds good

[egghat]

That's the main problem for adoption of arch, subversion or Aegis. All of these lack support for NetBeans, Eclipse and the other important IDEs.

I guess the moment one of the next generation version controls systems gets good IDE support will be the break-through for this IMHO needed technology improvement.

Bye egghat.

Al Viro's review of subversion

[hellgate]

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.

Short and concise as ever.

http://marc.theaimsgroup.com/?l=linux-kernel&m=1 03 402696209262&w=2

Re:Al Viro's review of subversion

[velco]

I would't take it _too_ seriously. You can hardly get Al Viro to say anything nice for anybody's code. And account for the usual Linux kernel arrogance and the difference in the coding style.

~velco

Damn...

[Pedrito]

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.

Re:Damn...

[Kaa42]

For Windows there is an excellent GUI called TortoiseCVS. It integrates with Explorer by overlaying icons on the files in the sandbox with own small icons indicating modified files, files with a conflict etc. You can perform all the important functions by simple context-menu commands on the directory, single- or multiple files.

This program is really the reason I started using CVS, it removed all the unnecessary cruft that is in WinCVS for example.

There is a move to make a TCVS like client for Subversion but I dont know at what stage it is at the moment

Re:Damn...

[Garrett Rooney]

actually, the command line svn client has a much simpler interface than cvs. the general concepts are similar, and it keeps many of the same commands, but you don't have the dizzying array of flags for each option that you'd find in cvs.

Re:Damn...

[philip_bailey]

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.

The CVS commands for these:

cvs commit

cvs update

Horrendous. Really?

Re:Damn...

[Anonymous Coward]

Yes. For a start, the CVS command line client is non interactive, which is a pain in the ass if you are using SSH authentication and have to enter your passphrase every time you want to do something. You also leave out most of the command; E.g.

cvs -d:pserver:anonymous@cvs.project.sourceforge.net:/ path/to/cvs/root checkout file

Oh wow, yeah, now thats so obvious isn't it?

Re:Damn...

[Majix]

For a start, the CVS command line client is non interactive, which is a pain in the ass if you are using SSH authentication and have to enter your passphrase every time you want to do something.

That's what's ssh-agent is for, you upload your public key to the machine running CVS and the agent running on your machine authenticates you without a password.

cvs -d:pserver:anonymous@cvs.project.sourceforge.net:/ path/to/cvs/root checkout file
Oh wow, yeah, now thats so obvious isn't it?

1. You can get rid of everything up to the "checkout" by putting it in your CVSROOT variable.
2. No subsequent updates/checkins ever need this information again as it's stored in the CVS data in the directory. So it's a one time deal.

Subversion replaces the cryptic CVSROOT with a "normal" url, so you'll be typing something like "svn co http://someserver/repository module".

Al Viro hates it !

[BESTouff]

I didn't look at the source myself, but here is a quote from Al Viro who did (and I find he has good taste):

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

Re:Al Viro hates it !

[Anonymous Conrad]

I didn't look at the source myself, but here is a quote from Al Viro who did (and I find he has good taste):

What, so you're not only a slashbot, you're an *alvirobot* too? :-p

There's nothing wrong with svn code. If you ever program for a living, you'll have to deal with other people's code. You won't like it all. Grow up.

Non-Apache 2 server?

[g4dget]

The use of Apache 2 is a show-stopper as far as I'm concerned: we have no interest in migrating to Apache 2 in the foreseeable future. Is there a small, simple standalone server for subversion, or can I run it over ssh? Does subversion work with non-Apache WebDav implementations? Is there a CGI version of its server component?

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.

Re:Non-Apache 2 server?

[theefer]

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 !

Re:Non-Apache 2 server?

[RupW]

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.

As noted above, there is a standalone protocol in development. There's also a pipe module to exactly mimic cvs over ssh.

If you strip down apache's configuration enough, it doesn't eat too many resources, though (can't get exact numbers from here, sorry) and it pretty much runs everywhere itself.

Re:Non-Apache 2 server?

[philip_bailey]

The suggestion in the documentation is that you run an Apache 2 server in parallel with your main (v1.3) server on a different port. Is there any reason that this would be a problem?

Re:Non-Apache 2 server?

[Anonymous Coward]

Yeah. It's fucking stupid.

Why the hell should you have to run two instances of a web server just for source control? What about servers with limited resources or under heavy load?

Re:Non-Apache 2 server?

[mgkimsal2]

If the server is meant to be a development server, I'm not sure why it'd be under 'heavy load' - too many commits? You probably shouldn't be running a dev environment on a production machine anyway. And if you're in need of a multi-user environment for version control, you are probably able to afford a new 'low end' (300 mhz?) machine to run things on.

I'm doubtful (for now).

[g4dget]

People like to complain endlessly about CVS and its quirks. And, yes, it does have quirks. But CVS mature, it works, and its quirks really don't affect day-to-day development in most environments.

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.

Re:I'm doubtful (for now).

[theefer]

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.

Good point, but this is also a big concern of the Subversion folks. This is why subversion looks so much like CVS. The commands and aliases are almost all the same, and a great part of the comportment the users see also is.

The ViewCVS scripts has already been ported to SVN, though it's not perfect yet, it does work. The GUI is pretty much in development indeed : RapidSVN is a working one, yet not complete either. An Emacs mode, similar to the CVS mode, shouldn't bee too hard to code I suppose, this is just a matter of time, will, and knowledge of elisp :)

There was talkings about using SVN as a backend for a wiki too, this could be fun and really nice. A first draft had been coded by Greg Stein (if I'm not mistaken), but it was mostly test stuff.

Subversion still needs help and contributors. People keep whining about CVS not handling file renaming etc, and they also keep using complicated tricks to avoid those flaws. I know, I've done it too. The very same people look at subversion and say "mh, nice, but not mature yet, let's wait it grows up a little". I doubt it'll grow quickly on its own, it just needs some help from all these coders who *will* use it in a few months/years !

Believe me, once you've switched to svn, it just looks life is *so* easier. Try it, it won't bite, and you'll most likely love it !

Re:I'm doubtful (for now).

[Drakonian]

People like to complain endlessly about DOS and its quirks. And, yes, it does have quirks. But DOS [is] mature, it works, and its quirks really don't affect day-to-day development in most environments.

Linux does look somewhat better and cleaner than DOS. But there are lots of add-on tools for DOS that will need to get ported (GUIs, servers, word processors, batch files, etc.). Just the retraining required to get people to use it in a multi-user environment is pretty daunting--DOS 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 DOS; it seems to be just ticking along, doing its thing. So, I'm not convinced switching to Linux 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 Linux to give me enough confidence in it to try it.

Re:I'm doubtful (for now).

[chicagozer]

Not to start a flame war but why not just fix CVS?

If the svn feature set isn't that much richer than cvs, why bifurcate the developer community? Does the fame and glory associated with having a new shiny program outweigh the adoption hurdles?

I am all for having choices and options -- I love it, but isn't a fundamental tenet of Open Source having the ability to improve and amend a program? A complete rewrite sounds more like a closed source reaction.

But seriously, I am just a long time CVS user who is patently lazy and wants all of these neat new features in CVS without any migration or disruption or effort.

Cheers!

PR for arch

[tomlord]

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.

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 ... well, just 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.

Re:PR for arch

[srussell]

This is really unfortunate, Tom. I'm sorry to hear this.

The reason why we chose Subversion over Arch, and probably a reason why Arch isn't getting as much attention as Subversion is, is because of Arch's dependancy on shell scripts. This removes any incentive for a heterogeneous software development shop to use it.

I can argue the merits of Subversion over Visual Source Safe to my clients, but Arch is a much harder sell.

Good luck on finding employment, by the way!

Re:PR for arch

[IamTheRealMike]

It'd be good if you could state some specific criticisms and arguments for arch vs subversion. We don't all have time to follow many dev lists closely (I follow several and to do it properly takes time). In particular, considering how different arch is from CVS/SVN, what are the advantages? Subversion may not be perfect, and the need to run Apache 2 scared me off, but it has the advantage that it takes all of 2 minutes to learn it if you have used CVS.

For instance, when I set up my project a few months ago, I did look at other code control systems, but CVS won because everybody had it practically installed by default, and it was good enough. Considering how many different commands there are to do very similar operations in arch, it'd be better for you to give it a proper intro methinks. The Linux Journal article just left me with questions.

Re:PR for arch

[RupW]

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.

There once was a company called Madge Networks (well, still is). In the early days, they made Token Ring cards that were clones of IBM cards. They didn't have the big name and reputation of IBM. They didn't have a significantly better product. So how did they compete? They were easier to deal with than IBM.

Are you as easy to deal with as the SVN team?

My impression is that you're trying to highjack funding from the SVN team by telling them that your product is better and collab.net should pay you instead. But collab.net want a CVS replacement for sourcecast and that's what they're paying for.

Re:PR for arch

[Anonymous Conrad]

Is arch better than svn? Don't know. It makes too many assumptions that XYZ posix utility is actually the GNU one. My Solaris box doesn't play along with that, and that's a showstopper for me until I can find a *lot* more time to play.

Are you ever going to make a Win32 version? How?

Re:PR for arch

[Daniel Phillips]

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.

There's no way somebody with your talent would not be snapped up, if you're known to be available. But I suppose you're not interested unless you can work on Arch fulltime?

I agree with the other respondent that the dependancy on shell scripts is a perceptual problem. Considered Python? Dependency on diff is not so great either. Actually, the binary diff used by Subversion and XDelta (the code came from XDelta I believe) is only a couple of hundred lines long, and very easy to use.

Re:PR for arch

[fferreres]

Tom, what is it that you are asking for? You'd do a lot better setting a goal and asking something specific, and saying what you will do if you reach a minimun set of funds to keep developing arch and then see how things go.

If for the time beign you are not lucky, you should give up and go on, you surely are talented and able to find a job soon if you want to play by your bosses rules (that always works).

Whining you are broken will only get you "condolences" and things like that.

Re:PR for arch

[tomlord]

> [arch isn't portable beyond unixen because
> it's largely written in sh]

Just as a small clarification on a technical issue:

1) In some sense, yes, that's an obstacle.

2) It is very portable among solid Posix and nearly-Posix systems. It's not terribly useful as it stands on cygwin because (I've been told) `fork/exec' is very slow on cygwin.

3) Most importantly, though, and a bit unlike SVN, arch is designed to be implemented more than once. It's tiny enough to rewrite (say, in Python or Perl) in just a few man-months. It's based in part on the idea of standardizing repository formats, exchange formats, and so forth. In other words, from the point of view of whether or not to support finishing arch, you have to regard it not just as a particular implementation, but as a collection of standards that are effective, simple, and cheap and easy to (re)implement in many different contexts. It's a bit like designing a cataloging system for libraries -- you think bigger than just one implementation.

(Regarding other comments in this "thread", about "get a job", or "you're just trying to steal funding from svn", etc. Well, those aren't bad advice/concerns/objections to discuss -- but I don't think the blog format really supports that kind of discussion -- so I'm going to let them go without direct reply.)

Re:PR for arch

[Ed Avis]

In principle a version control system doesn't need to use diff at all. It could just store each revision of each file in full. That's probably what I would do if I implemented a VCS myself. Then if disk space gets tight, there can be a daemon which converts some of the complete copies into diffs against the latest version. But that doesn't need to happen on every checkin.

An interesting alternative to storing diffs, but still saving disk space, is to use compression such as bzip2 to squeeze redundancy between the different versions. If you concatenate all the different revisions in a single file and then compress it, you'll probably use just as little space as compressing an RCS file or other collection of diffs. But it might be too slow to do this in practice.

Must every subversion user have a UNIX account?

[Anonymous Coward]

I've always hated this about CVS - it's impossible to lock down in a multiuser setting. Any user with repository write privledges can wipe out or corrupt the repository (intentionally or otherwise).
UNIX accounts and source control users should be seperate for a million reasons (security, isolation).
Does Subversion fix this particular CVS shortcoming?

How does this compare to OpenCM

[Anonymous Coward]

OpenCM looks to me to be much more useful and stable than subversion.

Re:How does this compare to OpenCM

[Anonymous Conrad]

OpenCM [opencm.org] looks to me to be much more useful and stable than subversion.

OpenCM 0.1.1alpha1-1 is now available for download from the releases page.

That's not mature/stable confidence inspiring. SVN aims to be a simple, stable replacement. It's been in development longer than that and is aiming lower. That's why it'll deliver first and be stable and usable.

Re:How does this compare to OpenCM

[Ded Bob]

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.

Re:How does this compare to OpenCM

[Anonymous Coward]

Release numbering's effectively meaningless these days. OpenCM's seen multiuser use in anger, and is designed as a cryptographically-authenticated distribution mechanism, not just a source code versioning repository. And, OpenCM's by the guys who are working on EROS - so they know what they're at when it comes to security.

If you spent just 1/4 of the time

[Anonymous Coward]

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.

Re:how does this compare

[Anonymous Coward]

Idiot moderators can't distinguish between 'funny' and 'flamebait.'

Well, there's no 'unfunny' so they've got to use something. Usually 'offtopic', though.

Actually, it'd have made a good serious question anyway. Sourcesafe isn't great but has the only really usable MSVC integration.

Somebody call TIPS!

[elixx]

Multi-user subversion?!
Isn't that a punishable offense now?

When can I see this on sf.net?

[Anonymous Coward]

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.

Seems like Poseiden UML to me...

[Anonymous Coward]

Last time I checked, Tigris sold there last "open source" project to Gentleware for non-open source development. This is not the type of thing I want to see if I adopt this CVS-alternative

Re:Subversion vs CVS-Alternatives?

[luther]

It is free

CVS operates on a per-file model

[Anonymous Coward]

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.

CVS Security depends on Unix

[Anonymous Coward]

That's the beauty of CVS - it follows the simple philosophy of Unix - rather than building it's own security system, it simply relies on the Unix system itself for security. Furthermore, for client connections, it doesn't impose a scheme, you can use SSH if you want, which is quite secure.

I've never found "directory versioning" to be a problem, nor the lack of atomic commits. Perhaps this is because CVS is so reliable, but if a commit fails, fix the problem (usually password or ssh error), and run the commit again.

Sheesh - directory smirectory...

[Anonymous Coward]

If directory handling is such a big deal for you, I believe there are add-ons that handleit for you. The basic thing is CVS works well enough, and is proven and reliable, that make it hard for people to switch.

I'd also have to wonder about how exp. you are with other tools. Ever used SourceSafe? PVCS? ClearCase? All have their own quirks and issues. You do need to be skilled enough in CVS (or any system) before you can make real use of it. It is true that unfamiliarity with CVS easily trips people up.

Tagging/Labelling in SVN

[Anonymous Coward]

I've gone through and read the "Subversion: The Definitive Guide" document, and overall I like the architecture and features. The one thing that I'm not sure about is how it handles tagging/labelling.

The basic idea is that since directories are now versioned in SVN, you can create a new directory for a project that is named MyProject4.2.1234 which is an inexpensive pointer to the main MyProject directory at the global revision of what you consider version 4.2.1234. I can understand how this works technically, I'm just not sure how practical this is from a user perspective.

At my company we do builds every other day on a given release version of our main product line and apply tags to code in CVS and labels to code in MS VSS to associate the release version with code revisions. The software is complex, serves different clients in different industry, and has a lot of developers on it, so inevitably code gets checked in that breaks some other feature.

Currently for the code that is in MS VSS it is easy to do a history on the entire tree from the last known working version, 4.2.1230 to the broken version 4.2.1234, because the tags/labels are tracked against the individual files. For the code in CVS, although CVS log doesn't return just a change history, we do have scripts that filter the output to give us what we need.

In SVN, each tag/label is a directory that intially points to a revision of the main project directory, but there doesn't seem to be any link back from the main project directory to the tags/labels so you can easily track the revisions of files against your versions of software.

To me, being able to easily track what changed when and went into which release versions is an important feature of a version control system. Do others see the SVN tagging/labelling process in the same light that I do, or are others handling tracking code revisions to release versions differently to not see this as a usuability issue?

Repository-Level Revisioning -- A Good Thing

[CyberLife]

My company recently switched from CVS to Subversion for all of its revision-control needs. By far the most difficult part of the transition was getting used to the idea of revision numbers being assigned to the whole repository, not to individual files. At first, the concept was alien to people, but once they understood a simple fact, it was a no brainer.

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.

Re:Repository-Level Revisioning -- A Good Thing

[jcr]

This is very much like TeamNet's "checkpoint" concept. In TeamNet, you made changes in your work area at will, and any time you wanted to remember the state of the project, you'd freeze a checkpoint.

This was a *very* cheap operation, since it consisted of supplying a name to the current state of the world, and creating a new "open" checkpoint.

To create a Work Area in TeamNet, you'd make a Virtual Copy, or VCP (effectively a symlink) to some checkpoint in the repository, which TeamNet referred to as the "Baseline". Your work area would only use physical storage for the files that you'd actually changed.

I'm glad to see SubVersion dealing with the need to know the entire state of the project, instead of leaving this burden on the developer. There are lots of times when adding a feature or fixing a bug means changes to a bunch of files, which I need to apply or rollback as a set.

-jcr

Listing of all known SCM software for Linux

[rickmoen]

Ian --

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

CVS renaming trick breaks history

[Earlybird]

Maintaining the history of individual files across renames is important. Certainly you could grab the entire cvs log output and jam that into the log message for the added file, but you would still break cvs annotate.

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.

Two replies, one post

[Anonymous Coward]

You are a 14-year-old gaybo.