KDE Switches to Subversion

Michael Pyne writes "It's official, after weeks of preparation, KDE has completed switching their source control repository from CVS to Subversion. KDE is one of the largest software projects to make the switch, and is the first major desktop environment to do so. Some of the goodies that CVS users are used to are still in the process of being switched over (including WebSVN), but everything seems to be working well so far." (The announcement of early April is no longer the operative statement.)

Comments

Obligatory

[Anonymous Coward]

Kongradulations!

Re:Obligatory

[Anonymous Coward]

I was going be a spelling nazi and pick you up on that erroneous 'd' that made it into your single-word komment, but somehow KDE threads don't really lend themselves people korrecting your spelling.

Re:Obligatory

[Anonymous Coward]

I was going be a grammar nazi and pick you up on that missing 'to' that should be between 'themselves' and 'people', but somehow my previous spelling error overshadows any authority I might have.

Re:Obligatory

[Anonymous Coward]

I was going to be a grammar nazi and force you into slave labor in a concentration camp, but somehow my conscience got the better of me.

Re:Obligatory

[Anonymous Coward]

Wouldn't that make you a nazi, sans grammar?

Re:Obligatory

[Anonymous Coward]

I was going be a spelling nazi and pick you up on that erroneous 'd' that made it into your

Come on, is it really that hard to use the proper term "gnazi"? ;D

Re:Obligatory

[Anonymous Coward]

Or a republican, but what's the difference?

Re:Obligatory

[Anonymous Coward]

Republicans lust for power, Nazis covet power, and Democrats just want power.

Re:Obligatory

[__aaclcg7560]

Republicans lust for power, Nazis covet power, and Democrats just want power.

And Ralph Nader got no power (which is a good thing).

I truly wished they have given a different name.

[cabazorro]

My managers simply refuse to use anything proposed by us, the development team, and named subversion.

That proves it

[vandon]

Subversion...Subvert...
The government has taken control of the KDE project.
Stay with Gnome!

Re:That proves it

[Venkata Prasad]

Government taken control of KDE project??? Did I miss something? I only know that the KDE project was planning to switch to subversions since more than an year and finally they did it. really... Kongratulations.

A much needed switch

[CastrTroy]

Its nice to see them making the switch. Having used both Subversion and CVS, I have to say that Subversion is much better. I hope more projects continue to do the same. Its amazing that CVS has lasted as long as it has.

Re:A much needed switch

[bosz]

Bye bye CVS. It was nice knowing you.

Re:A much needed switch

[Anonymous Coward]

The only downside is that I've had some friends unable to use the WebDAV method PROPFIND because some corporate firewalls have blocked it. Regular GETs will work, but you don't have all the info about the file. And trying to get a big organization's IT dept to change a firewall setting for one project is a huge struggle.

That and some people use Novell netdrive to access subversion like a regular drive which results in tons of small uncommented commits if they have write permission.

Re:A much needed switch

[RootsLINUX]

Yeah, I'm not a big CVS fan and I'm eager to start using subversion. Unfortunately, SourceForge still doesn't support it so I (and thousands of others) are stuck with CVS for a while. However, they're looking into it. Here's an excert from their site status updates:

Subversion Service: The research, analysis, and support gear-up needed to implement a Subversion service at SourceForge.net is now in progress. As with all SourceForge.net services, extensive analysis and testing must be performed to verify suitable levels of stability and scalability before a service can be rolled-out. We are expecting the initial phases of this effort to last several weeks, to be followed by the implementation of a testing environment which will be used for a live beta test by specific selected projects. Pending successful scalability testing, service details will be finalized and service will be offered to all projects. (Refreshed 2005-04-21, to show continued in-progress status.) (Last updated: 2005-04-21 Pacific)

Re:A much needed switch

[Will2k_is_here]

Bye bye CVS. It was nice knowing you.

Why is CVS dying? Why is subversion better than CVS? And why isn't CVS working to keep pace with the competition?

Re:A much needed switch

[Anonymous Coward]

>And why isn't CVS working to keep pace with the competition?

Because it was a mess, so some of the CVS developers decided to start from scratch, the result: Subversion.

Re:A much needed switch

[Anonymous Coward]

"Its amazing that CVS has lasted as long as it has."

Give Walgreens some time, they'll take care of it.

Re:A much needed switch

[flink]

If you setup SSL on the web server, they should be able to check out just fine using an https:/// url, as the firewall will have no idea what PROPFINDs are flying around.

Re:A much needed switch

[Dan Ost]

Subversion is being developed by the people who created CVS. They recognized
CVS's limitations and decided that it would be more painful to fix CVS than
it would be to start from scratch.

But don't worry about CVS, it'll be around for a long time to come.

Re:A much needed switch

[Miffe]

You can use BerliOS, they support subversion.
http://developer.berlios.de

Re:A much needed switch

[kdekorte]

Who cares about SVN when SourceForge's statistics engine has been down for 4 months. Really difficult to know what is being downloaded.

Re:A much needed switch

[Jon Peterson]

But don't worry about CVS, it'll be around for a long time to come.

It's the being around for a long time that I worry about.

Re:A much needed switch

[ckaminski]

Actually, I don't think it will. Once subversion corrects a few minor problems and cvs2svn improves a bit more with large projects, CVS will be relegated to the closets with RCS and SCCS.

Re:A much needed switch

[Anonymous Coward]

Which 'minor problems' do you mean, btw? Just spewing FUD?

Re:A much needed switch

[Anonymous Coward]

As someone who has used other systems like Darcs and BitKeeper, I have to say I can barely see any difference between subversion and CVS.

Re:A much needed switch

[Anonymous Coward]

Good question (your last question that is).

CVS could simply recognize it's limitations, accept that, and continue improving the command line flags and other details.

For instance is there something inherent in CVS that makes it impossible to "add" entire directories at once? No. Current in CVS you have to add the directory, then add each file in the directory, then add each file in each subdirectory, etc. And if you accidentally add the CVS metadata dir itself it craps all over itself. Why can't I just add the directory and have it automatically recurse? This is just an implementation detail on the client.

Why can't I do data-based searches on individual branches? Why can't CVS help me when the repository location changes? Why do I have to specify the "-P" flag to prune empty directories, why doesn't it do it by default. Etc etc.

Instead they just left CVS to rot and moved to Subversion. Okay fine but Subversion is much larger and more bloated, and it doesn't come installed by default on BSD or Mac OS X. (Yeah, that's a minor thing, but I'm not switching until I can work with a coworker and NOT require an extra download and install step. .. after all, if I do that, I'll just use Darcs or something that actually offers deep improvements of Subversion).

Re:A much needed switch

[gstein]

A phrase that I have used often: "CVS is resistant to change."

I'm not kidding. I've actually made changes to CVS before. You would not believe how impossibly difficult the thing is to change without breaking it. Change something *here* and it breaks way over *there*. It is a disaster.

Please go ahead and try to extend the add command as you describe. I doubt you would be able to do it. And if you *do* get it to work, then see whether you can get it to function with old CVSs, Eclipse, NetBeans, and CVSNT.

The CVS codebase simply could not be a starting point. Period.

Re:A much needed switch

[tyler_larson]

I can barely see any difference between subversion and CVS.

That's the point.

SVN is designed to be a direct replacement of CVS, keeping as many details the same as possible, and only fixing what's broken. Everthing SVN does differently, they do because CVS did it wrong. Only when they've reached their stated goals will they start will they start supporting things that were beyond the scope of CVS.

Re:A much needed switch

[Anonymous Coward]

you seem to be implying that you believe that Subversion is perfect in every way, and that there couldn't possibly be minor problems.

In which case, no one cares what you think, because you're obviously an idiot.

Re:A much needed switch

[Anonymous Coward]

http://subversion.tigris.org/ -- it's all there. Most of what you're asking is on the front page, you lazy piece of shit. Jesus, the link was in the submission and everything, what the fuck is wrong with you?

CVS isn't working to keep pace because the CVS developers put CVS into maintenance mode so they could work on the successor: SVN.

You are ultra-super-gimptarded.

Re:A much needed switch

[adamfranco]

Who cares about SVN when SourceForge's statistics engine has been down for 4 months. Really difficult to know what is being downloaded.

I'd just like to throw in a "Me too!". I love SourceForge and have several big projects there, but this is getting to be ridiculous. Luckily our main project finished its last day in the 90-something percent activity range, so I'm guessing that people are still finding it, but the lack of stats is making it much harder to find new projects that are developing rapidly.

Re:I truly wished they have given a different name

[Chris Burke]

Hey, that's neat, you can use SVN as a pointy-haired-boss detector!

Sorry about yours, by the way.

Re:I truly wished they have given a different name

[Henk Poley]

Then call it SVN, Subversions shorter name.

Re:I truly wished they have given a different name

[LMCBoy]

tell him/her it's named "superversion"

Why not everyone likes svn:

[Anonymous Coward]

Monolithic svn databases are vulnerable to irrecoverable corruption

Re:Why not everyone likes svn:

[Anonymous Coward]

How about you check out the new backend fsfs?

Re:Why not everyone likes svn:

[DarkDust]

If you're scared by the BDB backend then use the FSFS backend which is a filesystem based backend, like CVS uses RCS files.

We're using SubVersion for over two years now, versioning our in-house Linux distribution with which we're doing our products and we've never had any data loss (though we had some trouble with BDB back in the 0.xx days).

Re:Why not everyone likes svn:

[NixLuver]

Excellent article with excellent points; On the other hand, if you don't have backups, the same thing could happen with CVS, although the damage footprint would be different. Disk corruption due to bad memory is not uncommon - many people who experience this in Windows simply chalk it up to 'a virus' (even experienced technicians do). If the problem exists for some length of time beyond your last backup, you lose everything modified anyway. In small code trees, it's not a problem, but can you imagine working back through the code tree of KDE or GNOME to discover exactly which files are corrupt?

If you back up your databases from SVN nightly, you're still never more than 24 hours out.

Re:Why not everyone likes svn:

[caluml]

BDB, FSFS, CVS, RCS

Are you deliberately using acronyms, or is this really what you say.. :)

Re:Why not everyone likes svn:

[Anonymous Coward]

If you work on an svn-based project like KDE which is already run by somebody else, you will most likely be stuck with their choice of backend, more often than not you'll get all the hazards (and efficiency) of a Berkeley backend.

Re:Why not everyone likes svn:

[Speare]

ISTR TLAs give ROI over RSI, YMMV, HTH.

Re:Why not everyone likes svn:

[GuidoW]

This is why subversion has the svn dump command (or was it svnadmin dump or svndump? Well, it doesn't really matter) that you can use to do backups of your repository to _plaintext_ files, just like you would use pg_dump to backup your postgresql database.

Obviously, if you don't use the feature, it's pretty useless, but, hey, how often has it been pointed out that every serious project that uses computers needs a good backup strategy?

Re:Why not everyone likes svn:

[MarkGriz]

OMG, WTF? ICURAAJ. YNH.

Re:Why not everyone likes svn:

[Anonymous Coward]

LOL

Re:Why not everyone likes svn:

[limbostar]

But while using the Subversion client, you don't have to care what backend the project managers are using. If the project database crashes, it's not your fault as a user.

If you're really super ultra paranoid, you could set up your own svn repository with your favorite backend, sync it up with KDE's project, and work from there, but then you're just making trouble for yourself.

SVN in client mode uses .svn directories (similar to CVS directories) with XML files and such to manage your local copy. Those big bad BDBs never come near you unless you're managing the repository.

Re:Why not everyone likes svn:

[DarkDust]

If you work on an svn-based project like KDE which is already run by somebody else, you will most likely be stuck with their choice of backend, more often than not you'll get all the hazards (and efficiency) of a Berkeley backend.

But in this case you don't have to worry as it's not your problem any more ;-) And you're not the one to implement the backup (which everyone with a little common sense does). As a user you can't notice the backend differences anyways (except for a small corner-case: the speed of "svn annotate").

Re:Why not everyone likes svn:

[kfg]

. . .we've never had any data loss. . .

"Don't be silly man. Why, this revolver only has one bullet in it, and I've pulled the trigger four times already without getting shot. It's perfectly safe."

KFG

Re:Why not everyone likes svn:

[Anonymous Coward]

As a user you can't notice the backend differences anyways (except for a small corner-case: the speed of "svn annotate").

Actually for any large svn project, the users will notice a significant speed difference between a svn server that uses the efficient binary-formatted BDB backend compared to one that uses the ASCII-formatted FSFS.

Re:Why not everyone likes svn:

[DarkDust]

Of course if we had a data loss we'd just play in the backed up repository dump from the previous day ;-)

Re:Why not everyone likes svn:

[Anonymous Coward]

But while using the Subversion client, you don't have to care what backend the project managers are using. If the project database crashes, it's not your fault as a user.

It depends on whether you are an unfortunate user who has lost a huge pile of valuable commits from somebody's svn server after it suffered the dreaded Berkeley database corruption!

Re:Why not everyone likes svn:

[kfg]

Bugger, as it turns out restore does not support my head.

KFG

Re:Why not everyone likes svn:

[DarkDust]

Actually for any large svn project, the users will notice a significant speed difference between a svn server that uses the efficient binary-formatted BDB backend compared to one that uses the ASCII-formatted FSFS.

FSFS is not "ASCII-formatted". And I didn't notice any difference when I switched our 3GB repository from BDB to FSFS half a years ago :-)

Re:Why not everyone likes svn:

[Anonymous Coward]

For some stupid reason, whenever I see your posts, I translate KFG as Kentucky Fried Gerbils.

Re:Why not everyone likes svn:

[e40]

Can you just reuse the same RCS (,v) files from your CVS repository with SVN?

Regarding BDB, yes, I'm scared shitless. My company tried to use it to back an object database system. We had locking problems that forced us to write our own disk-based btrees (specific to our needs).

Re:Why not everyone likes svn:

[Anonymous Coward]

In fact, because fsfs is so effective and popular it will be the default for new repositories in Subversion 1.2. Release candidates are already available.

Re:Why not everyone likes svn:

[Anonymous Coward]

Yes, the lesson he got from the experience was 'binary storage is bad'. The lesson he should have learned is 'backups are good'.

Doesn't matter what format the files are if it's the filesystem, the hardware, or something else that causes your data loss.

If you lose data and have no way to get it back, it's your own fault, regardless of what tool lost the data in the first place.

Re:Why not everyone likes svn:

[Anonymous Coward]

We seem to have different views of FSFS vs BDB. On a 2GB project with a lot of branching I've measured a penalty of around 15-20% extra overhead for FSFS vs BDB. One of the svn authors has this to say: How FSFS is Worse [than BDB]

Re:Why not everyone likes svn:

[kfg]

Quite possibly because I've posted that.

KFG

Re:Why not everyone likes svn:

[limbostar]

That's ridiculous. The entire point of Subversion is that it uses atomic operations. If you update against a corrupted database, and so much as ONE FILE has a sync error, your local copy gets unrolled to where it was before you ran `svn update`.

So even if you could somehow connect to a corrupt BDB in such a way that the transaction could even start (instead of just returning an error before any files could be read at all), and you could download 99% of the changes before hitting a corruption, you'd STILL not be in any danger, because none of your files would have changed.

But it's nice FUD.

Re:Why not everyone likes svn:

[BarryNorton]

Hmmm, an academic who swears in such an article and whose homepage reads as follows: "Welcome, I work at the Department of Computer Science, University of Bristol, were I happen to be a reader."

Re:Why not everyone likes svn:

[Anonymous Coward]

Take a deep breath and calm down because what I said is not FUD and was not intended to be FUD. For complex reasons I didn't have access anymore to my previous local svn. That's why when the svn server suffered Berkeley Database Corruption Syndrome, causing all attempts by the admin to extract the data to fail, I lost all my work that had been committed previously to the server.

Re:Why not everyone likes svn:

[IdleTime]

You forgot "lollercopter !!!111!!one!!1"

Re:Why not everyone likes svn:

[Camel Pilot]

That is why I use CVS to manage my SVN repositories :)

Re:Why not everyone likes svn:

[jilles]

This has been posted in the last thread on svn and I don't agree. I've used subversion for more than a year now. I find it to a be a very reliable and easy way to put files under version control.

The reason cvs fanboys love having textfiles around is that, well, you really need them in the not so unlikely case that cvs messes up. One of the many things that svn fixes is atomic commits. In svn a commit either fully succeeds or fails. In cvs on the other hand it may actually fail halfway and leave the repository in an inconsistent state. When that happens, ascii files on disk are quite nice to have.

Svn fixes this by using a database and by not commiting changes to the database until everything is ok (not rocket science but nice to have when you are working with your most valuable assets: source code). In addition you can of course make incremental backups (on the fly) of any svn repository using svndump (which outputs a nice ascii representation of all commits in the order they occured). If you are really paranoid, you can do this every ten minutes (because it is incremental) and backup the db files every night.

If the worst happens (diskcrash?), you have the svndumpfiles, database backups and your user's local work directories to work with. That should provide everything you need to recover all data. If not, it is not a technology problem but a matter of backup discipline.

Now for all cvs users, migrating to subversion is as simple as creating a svndump file with cvs2svn and loading this dumpfile with svnload. Versionhistory, tags, branches etc. is migrated completely.

Re:Why not everyone likes svn:

[Anonymous Coward]

Maybe when you can write your home page without making any even little mistakes in a foreign language like Flemish (the author of that webpage has Flemish as his native language, not English), we won't think of what you said as being Flamebait. For that matter, if your own home page, which was supposedly written in your native language of English, didn't have such obvious howlers as "writing ... with the advice of ...", "[A] and [B] and [C] and [D]", "short-comings", and wasn't plagued by verbosity, you might be taken as a serious scholar.

Re:Why not everyone likes svn:

[Anonymous Coward]

How do you know that that home page belongs to the slashdot user BarryNorton #778694?

Re:Why not everyone likes svn:

[Anonymous Coward]

Because if you follow the link you posted and read the story he submitted to slashdot in January 2005, you will see he gave a link to his homepage (in his username): 'Evil Twin' Threat to Wireless Security .

Re:Why not everyone likes svn:

[BarryNorton]

If you'd the guts to post other than anonymously I'd answer your criticisms and explain my point further. Otherwise I shall just write you off as a troll, getting personal without the guts to afford me the same privilege...

Re:Why not everyone likes svn:

[plampione]

Another reason not to use svn is that it doesn't work on old versions of linux. For instance, if you try to compile it for Debian Woody (stable), it compiles fine, but then it gives a library error when started. Same thing on Redhat 7.3.

Who cares, you will say? Well, I use Debian stable for all my critical servers, due to the ease of doing security updates. Moreover, many of the people that need access to my cvs/svn server are running old versions of linux.

So, unless Tigris fixes this library problem, I will stay away from svn.

Re:Why not everyone likes svn:

[Anonymous Coward]

If we were to look at this objectively, we would note that it was actually you who started the thread with a totally uncalled-for ad hominem jibe at somebody who had never done you any harm. While we are on the subject of guts, did it take guts for you to make fun of a foreigner's English language skills on a very widely read public forum like Slashdot?

Re:Why not everyone likes svn:

[Anonymous Coward]

Heck, if your hard disk crashed, it would probably destroy most of your data be it in a monolithic binary database or scattered about in flat files. I would think that running Subversion or CVS on a server using ECC DRAM and which is periodically backed up would be an answer to this problem.

Re:Why not everyone likes svn:

[Anonymous Coward]

This guy's page says (basically) that if you have bad RAM, your repository can become corrupted. Well, no surprise there. With bad RAM, pretty much anything on your system can be corrupted. (That's another good reason to make backups.) This isn't exactly a mark against SVN.

Then he says "The moral of this story: Do not use binary file formats unless you can decode them and repair them". Of course, he also has GIF and PNG images on his website -- I wonder if he can decode and repair corrupted GIF and PNG files. I sure can't.

He says he's using CVS, so that "when shit happens (and shit happens) I will be able to repair it using, vi or emacs". Wow, good idea. Edit your repository's data files in vi -- that sounds safe.

This has been brought up before. Using a database to store data is not a crime. In fact, it's a really friggin' good idea.

Having no backups, and fixing the corruptions that occur (caused by bad hardware) using vi -- that's kind of sketchy.

Re:Why not everyone likes svn:

[Anonymous Coward]

So, unless Tigris fixes this library problem, I will stay away from svn.

s/Tigris/Debian/

Re:Why not everyone likes svn:

[Woody77]

Nope, SVN does something similar, but different, with the file-system-based backend.

SVN versions the entire repository with a single version, while CVS versions just a file, and that results is a fairly large fundamental shift in how stuff is stored and tracked.

I recommend you go read the free O'Reiley book on SVN.

Re:Why not everyone likes svn:

[Anonymous Coward]

It seems much more like you are dropping out of the discussion after having made your criticisms only because somebody else has spotted and criticised the hypocrisy of one of your criticisms. Seriously, what was/is your point? You are free to reply anonymously if you so wish.

Re:Why not everyone likes svn:

[uglyduckling]

yes

Re:Why not everyone likes svn:

[adler187]

Hmmm using the google translate I got this:

I Say There Raymond The Lawyers Asses gives Really Oilly Injections over Really Salty Internships, You Might Marry Vogons, Head To Head

Wow that makes total sense! I see the light.

Re:Why not everyone likes svn:

[BarryNorton]

If you were to look back at my post objectively, you would realise that I was putting down an obstensibly academic source because he swears in his article. My pointing out the general problems in his English was, if anything, to put that in perspective. Go back to sleep!

Re:Why not everyone likes svn:

[BarryNorton]

Please see my comment on other branch - essentially, however rambling my English, I try to represent myself appropriately in a professional context. Find swearing on my university homepage and I'll concede... but you won't. So now that we've addressed my (lack of) hypocrisy, let's return to yours: who are you and where's your homepage?

Re:Why not everyone likes svn:

[ckaminski]

The #1 library subversion depends upon is libapr which is an apache portability library, so if that's not present (because you didn't install apache, maybe?) then yes, subversion won't work for you.

Re:Why not everyone likes svn:

[ngunton]

I am using subversion quite successfully on both RedHat 7.3 (my workstation) and Debian Woody (my server). I compile from source. Not sure why you're having a problem, but just wanted to let you know that it can work...

Re:Why not everyone likes svn:

[Anonymous Coward]

Disk corruption due to bad memory is not uncommon

If you're doing mission critical work on a server without ECC memory, you deserve data corruption.

Re:Why not everyone likes svn:

[Anonymous Coward]

I didn't denounce your criticising of his swearing (I too don't like it). What I found objectionable was your hypocrisy in criticising the English skills of a foreigner when your own English skills were not - on the available evidence - beyond reproach. More generally, such criticisms are very weak compared to possible criticisms of his assumptions or of his logic.

Re:Why not everyone likes svn:

[plampione]

Thanks - you are right. So now I have to find a way to compile that library... there are many machines that need cvs/svn but not libapr. But all in all, it might be too much hassle for me to install libapr on all machines (including cygwin ones) just to use svn.

Bah, perhaps I am turning into a luddite.

Re:Why not everyone likes svn:

[kaiidth]

Umm... you're overdoing it a bit there with your "professional context". He makes it perfectly clear; this is why it doesn't include lists of publications and all that good stuff, but instead comes with his link list, his hometown and a nice little picture of his house... and the view from his chair. I'd have thought that the miscellania on that page are pretty much uniformly informal.

Personally, I've always rather enjoyed his mode of speech, which IRL generally reflects a pretty honest outlook on the world... which is a rare, nay, freak occurrence in a "professional context" in which two-thirds of the people involved are out for nothing so much as personal glory. But that's probably just me.

In closing, I don't know if you've ever tried moving to a foreign country and living there on a semi-permanent basis, but I have, and I can tell you that it's fairly difficult to separate "idioms everybody uses, but which some guy on Slashdot might consider rude" from "idioms everybody uses, and which are fair game in most contexts". Just sayin'.

He's a nice guy, so feel free to drop him a mail if you feel he's been inaccurate and I'm sure he'll update the page in question accordingly just as soon as he has a chance. It certainly needs updating - that page is ancient and the info on it is well out of date.

Re:Why not everyone likes svn:

[BarryNorton]

I don't know if you've ever tried moving to a foreign country and living there on a semi-permanent basis, but I have, and I can tell you that it's fairly difficult to separate

I have, and as an academic. Informal is fine in an appropriate context. You'll note that many academics, and indeed industry researchers, keep a blog for this reason - to keep things seperate.

Re:Why not everyone likes svn:

[kaiidth]

Good, then you'll understand the difficulty. Which country was it, out of curiosity? It doesn't seem to feature on your CV, unless you mean the (semi-permanent?) summer schools.

As I say, if you feel his site contains inappropriate material, feel free to let him know directly. As an academic, I'm sure you're aware that it'd be far more appropriate than beating the subject to death on Slashdot.

Re:Why not everyone likes svn:

[Anonymous Coward]

"Obstensibly"? Probably not. Not even in US spelling.
Try "ostensibly".

"Seperate"? No.

Have a nice day, O professional academic :D

Re:Why not everyone likes svn:

[Anonymous Coward]

I think you should get a haircut and a new pair of glasses before you start criticising others.

And stop loving yourself so much - it makes me sick.

Re:Why not everyone likes svn:

[turbidostato]

"One of the many things that svn fixes is atomic commits. In svn a commit either fully succeeds or fails. In cvs on the other hand it may actually fail halfway and leave the repository in an inconsistent state. When that happens, ascii files on disk are quite nice to have."

I bet here and now you *never* had a problem due to the non-atomicity of CVS.

And I'll go further and I'll bet you can't provide information about *any* single real situation where the fact CVS stores file history in ASCII has been useful to repair a problem due to the non-atomic CVS nature.

I'm waiting.

"If the worst happens (diskcrash?), you have the svndumpfiles, database backups and your user's local work directories to work with. That should provide everything you need to recover all data. If not, it is not a technology problem but a matter of backup discipline."

Now I will ask about how is this *any* different from a CVS environment where you have rsync copies, hard symlinks or just plain tarred backpus. And easier!

Re:Why not everyone likes svn:

[BlueLightning]

STFU.

Re:Why not everyone likes svn:

[henkm]

Backups are fantastic. But you don't always know that your file is corrupted. Sometimes backups are overwritten before you know that a file is corrupt. When this happens, you want to have some mechanism to recover.

When (not if) every mechanism to recover fails, it is useful if you can repair it by hand. Sometimes you can repair binary data by hand (when fsck fails you can just poke a few bits in the right place on /dev/hda and do the work), but when binary formats get hairy it becomes difficult...

The lesson that I learnt is that I avoid binary formats where possible, unless I can regenerate the binary data from some human readable source. Of course, you cannot always avoid them (encrypted and compressed files are prime examples).

Re:Why not everyone likes svn:

[BarryNorton]

I'll stick it on my fucking homepage right next to this shit, then we'll all be even... Jesus!

Re:Why not everyone likes svn:

[BarryNorton]

No, longer term than a Summer School - I've spent periods of months in Germany on more than one project. I have every sympathy with the language issue but I didn't even realise he wasn't 'native' because his English is generally great and 'were/where' is a mistake of someone typing quickly (as me above in this thread), especially a fluent or at least semi-fluent speaker, not someone struggling to express anything... check his article, it's completely fluent, it's just not academic language. It's hardly fitting for me, as a junior academic, to tell him personally what to put on his university homepage. Hopefully a colleague would tell him that, just as you wouldn't use language like "up to your chin in shit" in class, so it belongs in a personal blog, not on a staff homepage. Finally - and this is my last word on the subject - a blog that did offer such opinions, and in such a tone, could then be judged as such (i.e. as someone running off at the mouth with an over-stated personal opinion, not an academic article).

Re:Why not everyone likes svn:

[kaiidth]

Germany eh? Gut gemacht! :-)

Yes, his English is pretty good.

OTOH, as my last word, I would disagree with the following: It's hardly fitting for me, as a junior academic, to tell him personally what to put on his university homepage.

Seeing as he has read and commented on this thread, he has inevitably seen your posts. Your opinions on his university homepage have almost certainly been noticed as well. So you have, if you like, 'told him', although you chose to do it in the third person, and by voicing your point of view to whatever percentage of 800,000-odd Slashdot logins happened to be reading at the time, rather than directly. Ultimately, that's your choice; I just don't see the logic by which it is preferable to attack a person in front of Slashdot than to simply compose and send a polite email. Again, that's probably just me.

Re:Why not everyone likes svn:

[Eil]

Newsflash: All databases are vulnerable to irrecoverable corruption.

(That is, unless you back them up regularly.)

Re:Why not everyone likes svn:

[Eil]

Note also that the author of the blurb linked to above says that he put dodgy memory in his system and was shocked and amazed that data corruption occured. Then proceeded to blame subversion. Idiot.

Re:Why not everyone likes svn:

[fcgreg]

Boy, here comes the FUD-train. This is essentially all the article you posted contains. For example, consider the following:

• The author lists minuscule details about his configuration. In other words, was he accessing the repository through the file-system, or through SVNServe process, or through Apache mod_dav_svn, etc.?
• If it was through the file-system, were his file permissions correct? Had he followed the copious warnings in the Subversion manual about allowing "Multiple repository access methods"? Without such information we have NO WAY OF VALIDATING anything he says as true, correct, valid, appropriate (you get the picture).
• Exactly WHAT VERSION of Subversion was this? There is a general date from back in 2004 near the bottom of the rant, but there is no indication if this date belongs to the article-at-large or not. Furthermore, this in itself gives us NO IDEA which version he was on. Was it even a non-beta version?

Now, I'm not trying to deride the author too badly, but trying make a point. If you're willing to take such undocumented, unsupported information on faith, why not take the word of thousands of happy Subversion users and administrators (not to mention the likes of the Apache project, KDE, and hundreds of others)?

I have managed MANY Subversion repositories over the last couple of years, with glorious success and ZERO complaints -- ALL WITH THE BDB BACK-END. I'm all smiles. I suggest you disregard such poorly-documented FUD. Instead, try actually READING the SVN book, which covers all of these aspects in heavy detail, possibly combined with the SVN users and/or developers mailing lists.

Re:Why not everyone likes svn:

[fcgreg]

I bet here and now you *never* had a problem due to the non-atomicity of CVS.

Well, you just lost your bet if you made it with me. It happens (although thankfully not regularly in most cases). Whatever... I don't even have the time (or desire) to prove it to you. It shouldn't be necessary.

I'm waiting.

For goodness sake, why??? Don't you have anything better to do?!

Now I will ask about how is this *any* different from a CVS environment where you have rsync copies, hard symlinks or just plain tarred backpus....

It probably isn't, aside from the technical details you've offered yourself. That isn't what the author was discussing. He was merely pointing out that if you're following any kind of industry standard practice for protecting your repository data, you need not worry about the anti-Subversion FUD of the original posts.

Re:Why not everyone likes svn:

[Anonymous Coward]

"I Seem To Recall Three Letter Abbreviations give Return On Investment, Your Mileage May Vary, Hope That Helps"

Re:Why not everyone likes svn:

[turbidostato]

"Well, you just lost your bet if you made it with me."

Please tell me what your problem was and then I'll can see if that was really an atomicity-related problem.

Re:Why not everyone likes svn:

[Anonymous Coward]

Please tell me what your problem was and then I'll can see if that was really an atomicity-related problem.

Keep waiting. Some people have better things to do than to justify themselves to abrasive, demanding, and ignorant fools. I cannot believe you have ever used CVS for anything more than a few files or single users.

Re:Why not everyone likes svn:

[turbidostato]

"Some people have better things to do than to justify themselves..."

Sure they have; meanwhile no facts that anyone really had any atomicity-related problem with CVS.

"I cannot believe you have ever used CVS for anything more than a few files or single users."

You are of course free to believe what you better want.

Differences

[ecsdrive]

What are the most important features that Subversion has and CVS hasn't? It's been a lot of buzz lately behind Subversion, but I didn't figure it out what CVS has that is so wrong/slow/bad for software versioning

Re:Differences

[dos_dude]

Apparently, subversion allows you to rename files (which is a clumsy process in cvs). It's also able to keep track of directories themselves. cvs doesn't care about diretories, only about files.

There are lots more differences though, but the two I mentionend certainly sound like they made life a little easier.

Re:Differences

[Pete]

Subversion's really intended to be as close to a drop-in replacement for CVS as possible - except with most of the huge design flaws fixed.

The feature I most notice (I use Subversion at work, albeit with a fairly small dev team) is the ability to do handle file renames properly (preserving history). Atomic commits (of groups of files) are also nice.

There are lots of other important features of course, but I tend to use it just as a better CVS - which role it fills admirably.

Re:Differences

[Chris Kamel]

Check this for a detailed checklist of what each of the major version control systems support/doesn't support.

Re:Differences

[Alan]

Check the main subversion page for some examples, or try that google thing.

Re:Differences

[Chris Burke]

I'm a fan of the atomic commits, with a single revision number for the repository. This makes it trivial to find a group of files that were checked in together and thus theoretically work together. This is important -- it isn't enough to just say "give me the version of foo.c two checkins back" without knowing what other files changed and what version of those files that foo.c was tested with. With CVS we would hack this functionality on top of it (you could use tags, but that was clumsy). Subversion gives it to us for free.

Oh, and "svn log | less" doesn't lock the database preventing others from checking in/out. :)

Re:Differences

[Anonymous Coward]

There are many...

The main one tends to be lack of tracking of file/directory renames. CVS does not really handle this at all while Subversion handles this very well.

Subversion also treats a commit of changes to multiple files as an atomic operation. This is a major benefit. You can easily see what all went into a specific commit (bug fix/etc) without trying to track down each file that it happened to. You also never have to worry about part of your commit being on the server and part of it not. It either is committed or it is not. CVS can not do that. (Well, beyond a single file that is)

Another major issue is the client/server relationship. Subversion has a very clean client/server interface. It is orthogonal, well designed, and relatively low overhead. CVS can not claim this to be the case. In fact, CVS's client/server features were bolted on after-the-fact and show it.

Subversion can work via HTTP/HTTPS protocols via an Apache plugin. In fact, it is not just HTTP but WebDAV and DeltaV protocol based, which means that there are other tools that can play with the repository as a auto-revisioned filesystem.

Subversion makes it possible to do some advanced web interfaces rather easily, such as the Insurrection http://insurrection.tigris.org/ does.

For me, once Subversion 1.1 came out there was no reason to look back at CVS other than legacy systems. (Subversion 1.0 was already better but it was 1.1 that finally put be over the edge.)

Re:Differences

[DarkDust]

What are the most important features that Subversion has and CVS hasn't? It's been a lot of buzz lately behind Subversion, but I didn't figure it out what CVS has that is so wrong/slow/bad for software versioning

• File/directory renaming. This is one of the most important things: you can easily move files around in a repository and thus rearrange your project directory structure. I'm forced to work on a big commercial project where we use CVS and the directory layout has grown like a cancer because some idiots couldn't get the layout clean in the first place and noone was able to correct it later (the CVS admin lacks the knowledge and the work necessary has become too big). This is a common CVS problem.
• Atomic commits.
• Cheap copies (which are used instead of tags and branches, more on this below).
• Optional WebDAV support.
• True binary file support (SVN only stores the deltas to previous versions while CVS has to store the complete file again if something changed... try versioning a 128MB binary file with CVS and watch your disk usage go up by 128MB with each commit).

There are two things that you'll find different when comming from CVS:

• The first is the fact that you don't version single files but the whole repository. This is very strange at first, but you'll quickly notice that it's much better than versioning single files as most of the time a source change like a feature implementation affects more than one file. With CVS you don't know that two files were changed at once and that these changes belong together: with SubVersion you instantly know because you see that at revision XY two files where changed.
• The other thing that seems odd is the "lack" of branches and tags like they're used in CVS: in CVS the repository file path stays the same while the working copy content is different according to the tag/branch. In SubVersion, you'll make a copy of a directory (in the repository) to start a branch. Thus the file path is different. I think the SubVersion way is cleaner and also more user/developer friendly but people that use CVS for years won't agree, I think ;-)

SubVersion as a whole has more clean, thought-out-design feel, IMHO. Being a former CVS user myself I guarantee you that after working with SubVersion for a while CVS feels a bit hacked together.

Re:Differences

[SpryGuy]

Perforce has handled file renames and atomic commits for years now. I'm just curious why Perforce isn't used more widely, as it sounds like Subversion is just now trying to catch up with where Perforce has been for a long time now.

Re:Differences

[Woody77]

Price difference. Perforce was simply not an option for my small company. Subversion, on the other hand, is just as easy on the pocket-book as CVS.

Re:Differences

[smittyoneeach]

On wonders if there will be a git interface at some point...

Re:Differences

[bani]

"With CVS you don't know that two files were changed at once and that these changes belong together: with SubVersion you instantly know because you see that at revision XY two files where changed."

This is so huge it deserves mentioning twice . Combing through CVS logs for specific changesets is a major pita.

I actually converted some CVS repositories to SVN just so I could use SVN to read through commit logs and diff out changesets so I could apply patchsets to other trees. In SVN it is trivial. 'svn diff -r1679:1683' etc. With CVS -- it is hopeless.

Oh yes, and branches/tags don't suck in SVN like they do in CVS.

Re:Differences

[burymore]

One other difference I don't see mentioned: Subversion includes documented, well-designed APIs, at a number of levels. This allows clients to integrate quickly, natively, reliably, and conformantly.

By contrast, CVS ... just doesn't. So clients mostly integrate by running a cvs subprocess. This limits what you can do, it also exposes you to all those annoying "file-name quoting" problems. AFAICT, the only client that has implemented CVS directly is Eclipse. That team has done a manful job, originally and also in support, emulating as best they can the idiosyncrasies of the undocumented CVS client, but it remains an ongoing source of turmoil for anyone running a CVS server and extending it in any way. There are already two Eclipse Subversion clients (a JNI binding to the standard C libraries, and a complete reimplementation in 100% Pure Java), and they're both no trouble at all.

Re:Differences

[styxlord]

Once Subversion 1.2 is released (very soon) the only thing that Perforce has on Subversion is merge tracking (which they're looking at adding in 1.3).

I'd characterise Perforce as a Visual Source Safe replacement more than anything else. You have to ask the server for permission to edit files in your sandbox (there are ways around this but its not the norm) which basicaly means that unless your development environment is tightly integrated with Perforce you're going to spending a lot of time playing with the Perforce client instead of doing work.

CVS/SVN on the other hand are great because you can go nuts and do your own thing, then update/commit when you're done.

There's also the small matter of licensing, if you have a large development shop Perforce can get expensive.

Re:Differences

[Anonymous Coward]

It's Subversion, dammit! Most projects no longer follow that camel casing nonsense.

Re:Differences

[bears]

Comparing Perforce to VSS is grossly unfair. Perforce is a damm fine SCM. VSS is, well, just awful.

Perforce has good reason for making you specify the files you edit. Take a large source tree. Edit three files at random in wildly different parts of the tree. Now do 'svn status' or 'svn diff' at the top of the tree, like you're reviewing someone else's change. Perforce knows which files have changed, and you get the answer right back. CVS/Subversion have to scan the tree.

I also like the way in Perforce you can assign changed files to different changesets, and see what other people have in their changesets.

But I deployed Subversion in our company. We don't have really big trees. And now I'm glad I did. I now have a requirement to operate a mirror of the repository for a developer on a private net with no direct Internet access. I can access his net via a VPN, so I can use SVK to mirror our main repository to a repository on his net. He can work away, committing changes to his repository, and I periodically VPN in and sync up the repos. I don't think I can do that with Perforce.

More switching! More, more!

[Pete]

Great!

Now when are they going to be switching from Bugzilla to Trac?

(insert ha-ha-only-serious-cos-Bugzilla-scares-me smiley here)

Re:More switching! More, more!

[f1shlips]

Why does bugzilla scare you?

Re:More switching! More, more!

[DarkDust]

Why does bugzilla scare you?

Because it's ugly and not very user friendly... if you've seen commercial bug trackers or stuff like Trac you'll notice the difference. Don't get me wrong, Bugzilla is a valuable tool and it does the job it needs to do, but the UI is horrible.

Re:More switching! More, more!

[Pete]

Purely because I feel the UI is complicated. Of course I've mainly dealt with it on hideously large and complex projects like KDE and Mozilla, so the complexity of the UI may simply be a function of the project's complexity (or, more specifically, a function of Mozilla's complexity, as it was originally designed for Mozilla).

Note that I'm not meaning to slag off Bugzilla at all - it does the job and does it well, as far as I understand. But I wouldn't want to use it for the kind of software I work on (much much smaller and simpler than Moz).

My team is using a combination of Trac and Mantis at the moment - my boss likes Mantis better as a pure bugtracker, but I'm hoping to convert him after Trac 0.9. :)

Re:More switching! More, more!

[SComps]

I never took Bugzilla seriously mainly because of the overly complicated method of searching it, the silliness (ie: zarro bugs found) and the mere concept that it's just another 'zilla.

I'll admit all minor things (except the UI) but like was mentioned earlier about a company not approving the use of a product named "subversion" names mean a lot, and a professional appearance can mean far more than the underlying functionality.

Re:More switching! More, more!

[Anonymous Coward]

Subversion is not "FooBarPlus With Secret Sauce". It has the word "version" in the name, and it's a clever twist on words. If some company can't stand the name, they never wanted it in the first place, and just threw out an exceedingly LAME excuse.

I mean what the fuck, most people think CVS is a pharmacy.

Re:More switching! More, more!

[Anonymous Coward]

Why does bugzilla scare you?

Ha! And people call me mad when I say half the posters here are 'liza bots.

Re:More switching! More, more!

[xgamer04]

If some company can't stand the name, they never wanted it in the first place, and just threw out an exceedingly LAME excuse.

Well, I can't stand the name iPod, but I sure as hell want one anyway.

Re:More switching! More, more!

[gnu-generation-one]

"My team is using a combination of Trac and Mantis at the moment - my boss likes Mantis better as a pure bugtracker, but I'm hoping to convert him after Trac 0.9. :)"

"Fog creek software" also do an okay bug-tracker, as joel will never tire of telling you...

Re:More switching! More, more!

[bani]

mantis is very nice (the interface is only 10,000,000x better than bugzilla). its also trivial to install and configure, and its very fast. the only thing its lacking is svn/cvs integration.

how does trac compare?

Subversion + trac

[gregmac]

I recently switched my internal development from CVS to Subversion, and use trac (there site seems to be down right now) as a front end to it all. Trac is a web based interface (written in python) that is a combination wiki, bug tracker, source viewer, changelog and milestone tracker. It has some amazingly cool features, like the ability to put wiki markup anywhere.

Using a wiki for documenting code is somewhat handy, but what's even better is the wiki extensions trac adds. You can type "This is related to bug #236" and it will make it a link to that bug. The cool part is, you can do that anywhere -- such as an svn commit message. (There's also ways to link to milestones, revision numbers, etc)

I originally switched to subversion for the big features - the ability to move files/directories, and the simple (compared to cvs) tagging/branching support. Trac just made it that much better.

Re:Subversion + trac

[gregmac]

Ugh, did I really just type "there" instead of "their"..? knew i should have previewed

Re:Subversion + trac

[tuxpert]

Although trac is quite good and integrates well with SubVersion, it has a few disadvantages, the main one being no support for multiple projects.

Scarab, the open-source bug tracking tool that CollabNet's commercial offering uses and GForge, although cumbersome to setup are IMHO better alternatives if you're looking for bug-tracking tools to use along with SubVersion

--
Ravi

Re:Subversion + trac

[Pete]

Eh, it happens, don't worry about it :).

Good to see another Trac fan helping spread the word. Damn I love that software.

Quite seriously, it would be interesting to see a really major opensource project like KDE switch to Trac - though using Subversion is a necessary first step, so we'll have to wait and see if a few more old-school opensource projects (eg. GCC, OpenOffice, Mozilla, perhaps one of the BSDs) start making the transition from CVS to Subversion.

Re:Subversion + trac

[muckdog]

Bugzilla is pretty widely used as well. We are about to switch over to it.

Re:Subversion + trac

[cloudmaster]

It's pretty trivial to set up new instances of trac to correspond to new SVN repositories. If your repository contains multiple projects grouped by a folder, though, you have a point...

Re:Subversion + trac

[Anonymous Coward]

I can't get my dev team to use Trac. They just don't go to the webpage. They don't think they need to. They just don't find the timeline or wiki interesting and useful enough.

Trac requires a critical mass of active users to be truely useful.

As the main build guy, however, Trac is still very useful even if I'm the only one using it.

Re:Subversion + trac

[Pete]

I understand that Trac support for multiple projects (along with a few other features) is due soon - I believe as part of the upcoming 0.9 release.

Thanks for the pointers re: Scarab and GForge though, I'll have a look at them. Always nice to keep up-to-date with the alternatives. :)

Re:Subversion + trac

[mikkom]

We are using flyspray, it's simple and efficient (and free)

Re:Subversion + trac

[Trepalium]

We're probably more likely to see GCC and other GNU projects convert to GNU Arch over Subversion.

Re:Subversion + trac

[Drako2]

I work for a smaller company and we've been using subversion since the day it went 1.0.

Once we found out about trac we moved to that as well.

We have about 15-20 projects managed under trac for different clients, and we have no problems with them. A little bit of work in the initial implementation makes setting up instances later trivial. We've had great success with it and feel that multiple projects work well.

Re:Subversion + trac

[Pete]

Do you have any reliable information on this, or are you just guessing?

I'd think it very unlikely that any large project (GNU-ish or otherwise) currently based on CVS could convert to GNU Arch - it's just too different on too many levels. Whereas Subversion is under a perfectly acceptable free software license (even if it's not the GPL and it's not spiritually Free software) and it is a reasonable technical upgrade from CVS, while GNU Arch just isn't.

Re:Subversion + trac

[Anonymous Coward]

Whereas Subversion is under a perfectly acceptable free software license (even if it's not the GPL and it's not spiritually Free software)
To GNU, only a spiritually Free software license is a "perfectly acceptable" license. =P

Re:Subversion + trac

[Anonymous Coward]

I had that problem. But then I just stopped sending or reading dev related email. You need a good bit of leaverage to do this though.

Re:Subversion + trac

[pcraven]

I tried scarab about 8 months back. I found more bugs with scarab in the first 48 hours of using it, than I had bugs in my project. I spent too much time 'dinking' with Bugzilla. So I bought FogBugz, and it just worked without extra work.

My worst bug with scarab was that it started its 'index' numbers over again. So I had multiple bugs with the same bug number.

Re:Subversion + trac

[bani]

mantis has support for multiple projects, and has an excellent interface. very fast, simple and easy to use. the only thing its missing is cvs/svn integration.

Re:Subversion + trac

[rikkus-x]

Another vote for Mantis here. We've been using it for over a year and it's been great. It's fast, runs nicely on Apache/Win32, and is easy to use. It was also easy to hack the code a bit, so that it suited our needs a little better. I'd never touched PHP before and it was easy to see where to tweak.

Rik

Re:Subversion + trac

[Trepalium]

It's just a guess, but many GNU projects have a habit of avoiding non-GPL and even non-GNU components. If they did, however, it would help GNU Arch mature (the software itself is probably fine, but the supporting software isn't there yet).

Re:Subversion + trac

[Tronster]

I'm grateful for the information about Trac (never heard of it until this thread.)

I have heard of GForge, and have a partially installed copy on a box with SVN. I'm in the process of setting this up for a game development project, but still have some time before I commit the team to a SCM...

Trac looks "tighter" than GForge and may have some features GForge doesn't. Would someone express what they feel are the benefits of either one? And regarding multiple projects...does "multiple projects" mean multiple SVN's or mean many projects contained in one SVN?

Cheers.

successor to CVS

[moz25]

As I understand, subversion was more or less designed to be the successor (and replacement) of CVS. It's not a big surprise then that switching is a major issue. The users are already used to its methodology (contrary to e.g. linux kernel developers).

Re:successor to CVS

[Anonymous Coward]

Think you ment to write 'minor' in there somewhere. ;)

Re:I truly wished they have given a different name

[Anonymous Coward]

You mean this?

GUI frontend for SVN

[haluness]

I've been using SVN mainly for my documents, but hope to start using it for my code.

Right now I've been using the CLI and I was wondering if anybody knew of GUI frontends (especially for diff'ing).

Re:GUI frontend for SVN

[Anonymous Coward]

For windows we use TortoiseSVN http://tortoisesvn.tigris.org/

Re:GUI frontend for SVN

[slavemowgli]

Did you look into RapidSVN? I haven't tried it myself, but it may be an interesting alternative to TortoiseSVN if you want support for platforms other than windows.

There's also a Subversion plugin for Eclipse, in case you're using that.

Re:GUI frontend for SVN

[Artius]

I use SmartCVS (for CVS) and they have a GUI client for SVN now. http://smartcvs.com/

Re:GUI frontend for SVN

[Anonymous Coward]

http://esvn.umputun.com/ is a pretty good frontend.

Re:GUI frontend for SVN

[Anonymous Coward]

Since this is a KDE related article, I'm obliged to point out kdiff3. It is very useful with subversion as a merge tool.

Re:GUI frontend for SVN

[gregfortune]

Trac provides a nice web based diff tool and a bunch of other features.

Re:GUI frontend for SVN

[meonkeys]

There exists plugins for using subversion within Vim and subversion within emacs.

Re:GUI frontend for SVN

[MonsoonDawn]

The "Rapid" part of RapidSVN is nowhere to be found. Nearly every operation that hits the server is insanely slow. I've tried it several times over the last year and pitched it within minutes every time. The web-based interfaces are faster and easier to use. Unless the repository is on your workstation avoid RapidSVN.

The Subversion plugin for Eclipse is a reasonable alternative. Development seems to lag behind Subversion by quite a bit though. It can sometimes take weeks for EclipseSVN to implement new commands.

Re:GUI frontend for SVN

[MemoryDragon]

Well depends on how you see it, the devs currently are busy to implement everything which the eclipse CVS plugin can do, which is quite a lot. They are 95% there with small functionalities missing.
Nevertheless the plugin people usually deliver a new javasvn and subclipse version within a few days timeframe of a new svn version, and currently the plugin is pretty much the best svn crossplatform client you can get.

The BETTER desktop already switched!

[sofar]

xfce Already switched to svn weeks ago. Lightwight, slick, fast, and now hosted on SVN.

Re:The BETTER desktop already switched!

[Anonymous Coward]

You misspelled CTWM.

Re:The BETTER desktop already switched!

[Anonymous Coward]

He said `slick', not `ancient-looking'.

Re:The BETTER desktop already switched!

[Anonymous Coward]

You mispelled "bloated".

Re:The BETTER desktop already switched!

[Anonymous Coward]

I apologize. I actually did a cursory search of the xfce.org news page and it appeared that it was still in the planning stages.

I guess I should amend my submission to "KDE is the second major desktop environment to switch". :-/

This is what happens...

[gbulmash]

...when you let geeks name products.

Of course, Microsoft is coming out with their own alternative. It's called Coercion.

- Greg

Re:This is what happens...

[Anonymous Coward]

and YOU WILL use it

Re:This is what happens...

[LightningBolt!]

Stragely enough, Sun is introducing their own alternative as well.

It's called JSCRX.

Catchy, eh?

I would love to see how well Insurrection works...

[Anonymous Coward]

I have build Insurrection, an enhanced web interface to Subversion, that is very closely tied to the way Subversion works. I would love to see how well it handles a repository as large as the KDE repository. (Plus I think it is a good tool, but then I wrote it :-)

You can play around with it at http://www.sinz.org/Michael.Sinz/Insurrection/

Note that I am still in somewhat active development but the code is also in active use. It can be checked out with:

• svn co http://svn.sinz.com:8000/svn/Web/trunk

Re:I would love to see how well Insurrection works

[Anonymous Coward]

Michael come back to miggy and do some serious work :)

windows cvs

[smallguy78]

It's a shame there's no free windows source control projects out there, for open source software that runs on windows (which there is quite a lot). Subversion has a client, but no server.

There's cvs but it's still pretty crappy , and the gotdotnet.com one which is very slow. All the enterprise source control software for windows is fairly good too, just way too expensive for private use.

Re:windows cvs

[Anonymous Coward]

Subversion has a client, but no server.

You missed the part about "subversion"

Re:windows cvs

[tuxpert]

SubVersion is available for Windows as well.

Re:windows cvs

[Anonymous Coward]

Use the right tool for the job. If no subversion server exists for Windows, then install Linux or BSD on a spare PC and have at it.

Re:windows cvs

[Anonymous Coward]

Whe are switching from a windows based system from a company called Component Software. It is very easy to use and has a lot of good features, but it seems pretty limited in terms of size of repository. Anything much over 10,000 files and you either need a MUCH faster machine, or new software, which is why I am going with Subversion next.

Re:windows cvs

[langedb]

Actually monotone works on windows as both client and server.

Re:windows cvs

[BigWhiteGuy_27]

Perforce, while closed source, has a free version of their software that can be used for open source projects. You can find out more information about it here. Perforce has clients for just about every operating system you can think of, including Windows, Linux, BSD, and OS X.

Re:windows cvs

[Anonymous Coward]

It is actually rather trivial to run a subversion server on Windows if you like. That is how we run it for our development team. Took like all of 10 minutes to get it install, configured, etc.

http://tortoisesvn.tigris.org/docs/TortoiseSVN_en/ ch03.html

Will give you information on how to setup a subversion server under windows.

Re:windows cvs

[malloc]

Subversion has a client, but no server [for Windows].

What!? That is complete nonsense. Subversion has excellent and complete (client + server) cross-platform support. Linux, Windows, *BSD, MacOS X, Solaris -- you name it. They achieve this by using C and APR.

Maybe you should read HOWTO Setup A Server on Windows.

-Malloc

Re:windows cvs

[IainHere]

Can't tell if you're trolling, but this being a Subversion story and all, try googling it.

You could even try reading the fine Subversion red manual. Note that, for a simple setup using the file based repository (FSFS), you don't need any fancy-dan Apache or BDB, just subversion itself.

Re:windows cvs

[smallguy78]

Apologies, I misread: http://subversion.tigris.org/project_packages.html as not having a server, rather just not running on windows 98. I'll take a look, although does it have support for vs.net?

Re:windows cvs

[smallguy78]

I've read that Perforce is the software Microsoft user (with modifications), although they will be switching to to Team System when it appears this year - which should be good as they'll actually feel the pain of their own source control system if it goes tits up.

Re:windows cvs

[smallguy78]

"user" should read "uses". It's a shame comments.pl doesn't allow you to edit like most other forums do.

Re:windows cvs

[malloc]

It can be confusing.

AnkhSVN is a VS.NET plugin. However, I'd encourage you to check out the really excellent TortoiseSVN client. I think one of the main reasons people like IDE integration is they're so used to the extra hassle that first checking out, editing and remembering what files to checkin, that the lock-modify-unlock model imposes. With Subversion's copy-modify-merge model and TortoiseSVN's recursive-oriented commit dialog, I think tight IDE integration looses much of it's usefulness.

-Malloc

Re:windows cvs

[rbgaynor]

There is no reason you can't install both - I much prefer TortoiseSVN for most of my interaction with SVN, but it is convenient to have commit status at a glance from within Visual Studio (thanks Ankh!).

Re:windows cvs

[ckaminski]

Any gnome/kde based versions of TortoiseSVN? I'm so addicted to it on Windows that I want it on my linux desktop.

Re:windows cvs

[ckaminski]

Actually, you need libapr, which usually requires having apache installed, and both versions need to be compiled with the proper version of BDB.

I've found, in my experience, that it's best to build apache and subversion from scratch using your distributions BDB and Apache packages.

Oh, and make sure you svndump before you upgrade ANYTHING. Nothing sucks worse than thinking you had the right BDB version when you go to move a repository onto a new machine...

Re:windows cvs

[malloc]

I'm in the same boat. On the TortoiseSVN dev@ list there have been a few noises of someone working on a Nautilus plugin, but I have no idea if that's gone anywhere.

-Malloc

Re:windows cvs

[IainHere]

This has strayed rather offtopic, but let's continue, since I might learn something: I use svn with the file system repository. I certainly don't have apache installed, but you're right - "apt-get remove libapr0" does warn that subversion will be removed. I based my above assertion on the fact that, when using FSFS and a command-line interface to the repository (as in a local, single user setup, although you can NFS mount the repository so long as you don't use BDB), there is no subversion service required to be running - all changes to the repository are done through the client svn commands. So why does it need libapr?

It seems that libapr0 is a "free library of C data structures and routines, forming a system portability layer to as many operating systems as possible, including Unix, MS Win32, BeOS, and OS/2.", which explains the dependency. I'm very suprised that you have found it necessary to install Apache just for that. It still seems likely to me that a Windows version should be runnable without any dependency issues - my initial reading about svn scared me off slightly, because I thought I was going to have to install all of that stuff just to handle local revision control. My intention was to tell the OP that such a headache isn't necessary. In any case, thanks for the info!

Iain.

Re:windows cvs

[MemoryDragon]

Having compile SVN a while ago to get the javahl bindings (hopefully they will die soon) I noticed that you can compile svn without the libapr, it is just a matter of setting a flag in the configure...
You need the libapr only if you want webdav and http access anyway.

Re:windows cvs

[ckaminski]

APR == Apache Portability Runtime. Something similar to NSPR == Netscape Portability Runtime, similar to ACE or BOOST. A library designed to easy portability of file access, socket access, threading, etc.

In my experience, SVN will not build, webdav or otherwise, without APR installed.

Re:windows cvs

[IainHere]

Subversion on Windows, for local use and with FSFS, has no dependencies.

I tested like this:

1) Copied my FSFS repository from Debian to vfat partition of WinXP machine.
2) Installed TortoiseSVN on WinXP.
3) Checked out and updated, played with, committed to, repository on WinXP.

I know this excludes the "create repository on WinXP" step, but svnadmin is downloadable for Windows without needing to install any other dependencies. All of this shows that:

1) The OP can use SVN for their own personal projects on Windows without worrying about installing BDB or any Apache stuff (libapr being part of the installation set, the end user doesn't need to know about it). In fact, no services are running at all, and;
2) I have far too much spare time!

Most places that talk about svn are discussing its use in a multi-user client-server setup, which of course is more complicated. I was just trying to say that, if you're working alone, but want to have revision control, svn is much simpler than most tutorials imply.

Re:windows cvs

[IainHere]

You say you're interested in it "for private use"; in that case *you don't need a server* - all you need is to download TortoiseSVN. You don't need to worry about installing Apache, or BDB.

It's so easy, I'll describe the process in full:

1) Right click on folder where you want to create your repository.
2) Select "TortoiseSVN->Create Repository Here" - select "Native Filesystem (FSFS)"
3) Right click on directory you want to put under version control, and select "TortoiseSVN->Import"
4) Right click on folder where you want your working copy to be, select "Export", and type in the location of your repository (in format "file:///C:/myrepos").
5) Make changes to working copy, check in, check logs, all new files to the repository, blame, all from right clicks on the files/folders in the working directory.

Note that, for (3), if you don't want to put EVERYTHING under revision control (eg object files, exes), first make a copy of your files and delete the things you don't want to include. Then proceed to (3) using your "tidy" directory.

Actually, it never was

[Anonymous Coward]

The stopper problem with SVN posted in April was from february and fixed a bit later, but then used as an April' s fools joke.

Re:I truly wished they have given a different name

[LMCBoy]

D'oh!

TortoiseSVN

[Mustang Matt]

This is one of the best windows based svn clients I've seen.

http://tortoisesvn.tigris.org/

Re:TortoiseSVN

[Anonymous Coward]

It is also the only windows based svn client I've seen.

Re:TortoiseSVN

[MORB]

It's indeed very good. Does anyone know of any equivalent for KDE ?

Re:TortoiseSVN

[DeekGeek]

eSvn is a Subversion GUI client that is based on the Qt library.

Re:I truly wished they have given a different name

[mbbac]

You should just pronounce it like it is hyphenated.

But, this is the first I am reading of this. Why are they moving from CVS to Subversion? It would seem that if it lacks useful features available in CVS that KDE would stick with CVS.

This is great...

[Anonymous Coward]

now if only I could get subversion to install then
I can download the files.

Re:I truly wished they have given a different name

[dubl-u]

My managers simply refuse to use anything proposed by us, the development team, and named subversion.

Good that you mentioned it. for $50k a year, I'm glad to license them my own version control system, "Rule The Developers With an Iron Fist". It's actually just Subversion and Trac in a box with a pretty logo and some marketing collateral. Plus, a guy with a nice suit and good hair will come and spend two hours explaining things to them in short words and bullet points.

Or they can get the deluxe version for $100k per year, where the guy with good hair will also take them golfing and out to dinner.

merging

[Hohlraum]

I remember awhile back that the subversion guys said that merging/branching wouldn't outshine cvs for a couple more releases. Is that that case now? I haven't been following subversion development for awhile now.

Re:merging

[JSD]

Subversion has the same (poor) merging capabilities as CVS.

FYI, I use Subversion but merging in Subversion and CVS is not nearly as simple as with Perforce or Arch. I subscribe to the subversion dev mailing list and I think it's probably at least another 1-2 years before Subversion has merging capabiliies on par with Perforce, Arch, ....

If you're interested in doing lots of merging with Subversion then you'll want to look at svnmerge (http://www.dellroad.org/svnmerge/index). I haven't used it but it gets good marks from the svn users mailing list.

Re:merging

[Anonymous Coward]

Maintaining many long-lived branches is utter torture in Subversion. Even the Subversion books I've read either don't mention the issue at all (PragProg) or gloss over it and say "someday it will be better" (O'Reilly).

You see, Subversion doesn't have what some might call "labels" or what CVS calls "tags". It ONLY has branches. Some branches you can "treat as" tags, others you "treat as" branches.

Somehow, somebody thought this was a really cool idea. It's not. It sucks. Why? It's difficult to *move* a "pseudotag". So keeping track of your last merge requires you to *write down* the revision number of your last merge. Or store it in metadata somewhere, or in a file. WTF?????? What good is a revision control system that doesn't track merges, or at least make it easy for you to do???

In CVS I would create merge-point tags right after a merge. then next time, merge all the changes from the merge-point up to the tip of the branch. Then, move the tag to the new merge-point. Repeat as needed.

If you're adding a feature to a branch and you DON'T want it on another branch, just move the merge point without doing the merge. Not as good as arbitrary "cherry picking", but I could write out the commands to run and anybody could follow them blindly.

In Subversion I couldn't figure out a safe workflow that didn't involve copying meaningless version numbers, or doing weird steps involving deleteing/recreating a "tag", or checking out the "tag" and merging changes into it.

I'm going to laugh when the Subversion folks finally add real "labels" to subversion (they have to, to solve this problem). What, you mean the "everything is a copy" philosophy wasn't good enough?

It would be so easy though. Just allow folks to name revision numbers and refer to those names. Problem solved.

Just a little rant. Sometimes I get the feeling nobody is using multiple long-running branches. I would like to hear how others (like KDE) are going to handle this stuff.

Re:I truly wished they have given a different name

[Anonymous Coward]

If you reread it, it doesn't _lack_ the goodies. It's just that they haven't finished _switching_ to the new goodies.

Oh no!

[Fefe]

I hope they at least refrained from using berzerkeleydb as backend. I know several projects who have lost their repositories with bdb.

I personally have also lost data to bdb, but not in subversion. I would never be so mad to trust my source code to some broken database backend. How are you going to get your code back if there is corruption? strings?

The GNOME people are probably breaking out the champagne at this point. :-(

Re:Oh no!

[DarkDust]

You can choose between a BDB based backend and a filesystem based backend.

Re:Oh no!

[Homology]

We've been using Subversion at work for about year and a half (from about version 0.30), and still has not lost any data. But this is just anectotal "evidence". Did the project that lost their repositories contact the Subversion developers regarding this?

Re:Oh no!

[djmurdoch]

The disadvantage of the filesystem back end is the proliferation of files. You get a new file with every commit. You need to be careful that your file system works well with a directory that might contain tens of thousands of files.

But you shouldn't lose a repository if bdb corrupts -- you should just lose the commits since the last backup. If you're running without backups, then you'd better watch out for hardware failures, system theft, fires, floods, etc.

Re:Oh no!

[Lukey Boy]

Wasn't that uh, the point of the original post? He was saying that he hopes they (the KDE project) aren't using the BDB backend.

Uhhh...

[lorcha]

I am currently examining the FSFS repository that I use for my personal coding. Let me say this: "I defy you to make any sense out of the gibberish that is your FSFS backend."

If you have a random corruption, I severely doubt you're going to be jumping into the FSFS repository and tweaking it to fix it.

My solution: rsnapshot. Because the repository is filesystem-based, all of my backup history combined only takes up the same amount of space as my actual repository (god bless hard links). With BDB, the disk usage for my backups would be insane.

Re:So what?

[jakel2k]

Linus chooses ham sandwich instead of chicken.

And the point is that people who look up to Linus may begin to choose ham over chicken. Just like people who look up to the KDE development team, or who use the desktop is more likely to consider Subversion now.

Re:I truly wished they have given a different name

[EnronHaliburton2004]

The submitter was complaining that the SVN utilities lack features available in the party CVS utilities; such as SVNweb vs CVSweb.

He wasn't complaining that SVN itself lacks useful features available in CVS. There are enough improvements (Atomic commits, versioning of directories and permissions) in SVN over CVS that switching to the new system is compelling.

The utilities don't all need to work now anyways.
Any sort of large-scale migration like this is done in phases. Phase 1, switch the repository. Phase 2, switch the utilities, Phase 3, cleanup :)

No per file version numbers.

[Anonymous Coward]

I tried using subversion once, but couldn't get used to the fact that there were no file version numbers. That is, it's not easy to tell how many times a given file has been changed, just by looking at its version number. Also, when referring to an old version, the version number may be quite large, since the revision number is global an incremented for each change.

Am I the only one who is troubled by this?

Re:No per file version numbers.

[aweiland]

Not really. I use svn for personal use and CVS at work.

I find it confusing when working on two files that are the same version of our software and one says 11.2 and the other is 11.8. Doesn't make a lot of sense to me personally.

I find the repository wide revision numbers to be more intuitive to me.

Maybe I'd be on the same wavelength as you if I had learned CVS before SVN.

Re:No per file version numbers.

[6wl]

Project wide revision numbers and log messages are the 2 things as a Project Manager I find most useful!

Part of our build process reads the revision number from the .svn dirs in our tree and displays them on the title screen - bug reports coming back with a project wide revision, rather than just some stab in the dark like the date the bug was found, makes my job so much easier.

Re:No per file version numbers.

[aok]

Use the SVN property $LastChangedRevision$ which is similar to the CVS $Revision$ property.

Also, to see how many times a file as been changed, use SVN's log feature to show a list of revision numbers where that particular file was changed. I'm not sure the commandline for it since I use TortoiseSVN to view it.

Re:No per file version numbers.

[Anonymous Coward]

Am I the only one who is troubled by this?

Yeah. And it's pretty lame to be troubled by something so completely irrelevant as well. Get over it.

But then I used Perforce for years, which already did things this way. The advantages far, FAR outweigh any "psychlogical" issues you might have (and they're ONLY psychological... there is no ACTUAL drawback to doing things this way).

You're only troubled by it because you're not used to it. Just because it's different doesn't mean it's wrong.

Re:No per file version numbers.

[IainHere]

use SVN's log feature [...] I'm not sure the commandline for it

The syntax for that command is (you'll like this):
svn log foo.bar

Re:No per file version numbers.

[Anonymous Coward]

Of course Perforce has per-file revision numbers as well as a repository wide version number, so you can make use of both whenever they're more usefull.

Mindhive question

[JPriest]

Am I required to pretend to believe Subversion is better now?

Re:Mindhive question

[Megaweapon]

Absolutely. This is Slashdot afterall.

Re:Mindhive question

[Anonymous Coward]

Am I required to pretend to believe Subversion is better now?

Christ, no. You're required to honestly and fervently believe now that it has always been better. Next time check the FAQ before posting.

Re:Mindhive question

[Frank T. Lofaro Jr.]

Subversion has always been better than CVS!

Oceania has always been at war with Eastasia!

Try SVK

[Krischi]

SVK works well with subversion, and has support for star merges. The ability to work offline is another cool bonus. On the flip side, documentation kinda sucks right now, but its command set for every day use works in pretty much the same way as subversion's.

Re:Try SVK

[Anonymous Coward]

SVK is also slow as balls.

Re:Try SVK

[Krischi]

Have you tried a *recent* version of SVK?

Re:I truly wished they have given a different name

[menace3society]

For shizzle. People are always complaining about "Oh, God, this product has such an awful name, my boss would never use it. I have a million better ideas for names!" But they don't get that, it's open source, so if you want to have a Fork In Name Only, you can go right ahead and do that. Just write a script that will changes all instances of 'Subversion' (or whatever) to 'Project Management Pro Elite'. Piece of cake.

Reasons NOT to do it in an Eclipse environment

[standards]

I know all about Subversion and its advertised benefits, but then again, my organization is centered around CVS and it works for us (despite its well known limitations).

But since I need to reorganize my development environment (new development machines, etc), I'm curious - should I switch now?

My development environment consists of CVS and Eclipse on Windows, Linux, Solaris, and Mac (an amalgam, eh?) ... a small group of distributed developers working on a (currently) proprietary product based around Java and Perl.

I'd only like to convert and clean up my source code repository once every 5 years or so... so is this the time to do it, or am I just looking for trouble?

Re:Reasons NOT to do it in an Eclipse environment

[MemoryDragon]

Not really for trouble, SVN is stable, so is the clients and if you use eclipse, the eclipse plugin is excellent, but is misses small functionality here and there. (the main problem I have is detaching and reattaching a project still does not work yet, sync however works...)

Re:I would love to see how well Insurrection works

[Anonymous Coward]

I doubt they'd use Insurrection, since Konqueror doesn't handle the pages Insurrection generates (it's behind Safari as far as XML/XSLT support to begin with, and even Safari isn't working perfectly with it). Unfortunate, though, since it looks really cool.

MODERATION ABUSE!

[Anonymous Coward]

My parent comment made reference to an interesting opinion expressed by a well-known academic in the UK. It was certainly not intended to insult or enrage anybody, and therefore should not be considered as "Flamebait". Thank you all thoughtful moderators and meta-moderators.

Slashdot FAQ What do the choices in the moderation drop-down boxes mean?

• Flamebait -- Flamebait refers to comments whose sole purpose is to insult and enrage. If someone is not-so-subtly picking a fight (racial insults are a dead giveaway), it's Flamebait.

What about XFCE

[Anonymous Coward]

KDE's not the first of the major desktops to change, XFCE switched a few weeks back.

Re:What about XFCE

[Anonymous Coward]

You obviously don't unterstand the term "major".

Is Monotone still slow?

[Anonymous Coward]

Is the initial code sync-up still 2+ hours?

*sigh*

[[Xorian]]

Subversion is kinda behind the curve these days. I mean the whole concept of Subversion can basically be summed up as "let's make something that feels just like CVS, but doesn't suck." There are lots of free alternatives that provide much more advanced capabilities.

It's too bad they didn't chose something more advanced like Vesta, or Codeville, or monotone, or Darcs.

Re:*sigh*

[Anonymous Coward]

Unfortunately, a lot of the alternatives are like, "let's make something new, that's going to suck for the near future until we get the kinks worked out." Sure, they'll eventually become something great but for the present they're not really appropriate for a major project like KDE.

Re:*sigh*

[Anonymous Coward]

<irony>
yeah, it's SO STUPID to do these "it just works" things, instead of gee-whiz-bang uber-cool things.
</irony>

Re:*sigh*

[Anonymous Coward]

The fact that Subversion is "behind the curve" was one of its major selling points, as that means the design has had time to be tested, and as such we could be relatively assured that there were no major bugs lurking around.

In addition, Subversion "feels just like CVS", which was another major reason KDE made the switch. Many of KDE's most valuable contributors aren't programmers, and they generally use a GUI frontend to CVS instead of the client, so we needed something that was similar enough to what they were used to.

Then of course there are the concerns about the performance of managing one of the single largest code bases in open source, but I'm not qualified to talk about the performance of your suggestions, only to say that Subversion seems to be fast enough.

Re:*sigh*

[Anonymous Coward]

You take the engineering out of Software Engineering.

Re:*sigh*

[[Xorian]]

Unfortunately, a lot of the alternatives are like, "let's make something new, that's going to suck for the near future until we get the kinks worked out." Sure, they'll eventually become something great but for the present they're not really appropriate for a major project like KDE.

Well, I can't speak to the maturity of the others, but Vesta is the result of over a decade of R&D and has been in production use for microprocessor design projects at Compaq and Intel for over 6 years. Vesta's period of "trying something new" happened a long time ago, and the kinks have been worked out for years.

That's not to suggest that it's static (Intel employs two full-time software engineers to work on it), but it's been stable for a long time.

Re:*sigh*

[bani]

darcs' dependence on haskell means it is a non-starter for most. it is also very slow.

Re:I truly wished they have given a different name

[killjoe]

" My managers simply refuse to use anything proposed by us, the development team, and named subversion."

For the umpteenth time people. When you say things like this name your company. We all want to make sure we don't have ny stock in companies with this kind of management.

Re:I truly wished they have given a different name

[David Leppik]

Try calling it SVN, and pronounce it ess-vee-en. If that isn't enough, claim you've got a "demo license" of it, rather than telling them it's open source. Weirdly, most companies I've worked at which had problems with open source had no trouble with developers using demo versions of things indefinitely.

WTF

[eldacan]

The GNOME people are probably breaking out the champagne at this point. :-(

Excuse me!? Please don't spread the disgusting idea that GNOME people would rejoice at hundreds of FOSS developers losing their work.

There may be many "trolls" among GNOME and KDE users, but there are many intelligent people among the devs, who collaborate through freedesktop.org and even joke together, like on April 1st when they made planet.gnome.org point to planetkde.org and vice versa.

Apache switched to Subversion

[otisg]

I think that's also well-worth noting, as Apache is a pretty big and significant open source software player, and as such its migration to Subversion, which happened months ago, served as the "green light" for smaller projects's move to SVN.

When is SourceForge making this move?

Re:Apache switched to Subversion

[hawkeye]

Apache migrating was likely a "given".... Subversion is built using apr, after all :-)

Cheers,

- Hawkeye

Re:Apache switched to Subversion

[Anonymous Coward]

Sourceforge is working on it.

man svnserve

[Anonymous Coward]

should do the trick

Re:I truly wished they have given a different name

[RealAlaskan]

It's obvious you have some experience in government or corporate purchasing.

I'll put in a purchase order for the $1,000,000 version with the $100,000 per year support contract. That's the version where girls with good hair provide on site support.

Re:I truly wished they have given a different name

[WindBourne]

Hummmmm. For fun, send them links to Satan.

Shouldn't lose repos, but can...

[kupci]

But you shouldn't lose a repository if bdb corrupts -- you should just lose the commits since the last backup. If you're running without backups, then you'd better watch out for hardware failures, system theft, fires, floods, etc.

Well you shouldn't lose the repository, but you can:

http://www.cs.bris.ac.uk/~henkm/svn.html

But your backup suggestion is well taken - repositories should always be backed up. However, these sort of issues, are probably why so many folks are still using, and will continue to use, CVS. It simply works. I understand needing to go to backup if the hard drive crashes, but the database failing? I think, until SVN, or others, have major improvements over CVS, then we can switch. But this is sort of a point upgrade. Renaming files, directories - nice. Better merging would be great though. Monotone seems interesting, especially with the interest from Linus as a BitKeeper replacement.

Re:Shouldn't lose repos, but can...

[fcgreg]

I'm sorry, but the article you post is essentially FUD. For example, consider the following:

• The author lists minuscule details about his configuration. In other words, was he accessing the repository through the file-system, or through SVNServe process, or through Apache mod_dav_svn, etc.?
• If it was through the file-system, were his file permissions correct? Had he followed the copious warnings in the Subversion manual about allowing "Multiple repository access methods"? Without such information we have NO WAY OF VALIDATING anything he says as true, correct, valid, appropriate (you get the picture).
• Exactly WHAT VERSION of Subversion was this? There is a general date from back in 2004 near the bottom of the rant, but there is no indication if this date belongs to the article-at-large or not. Furthermore, this in itself gives us NO IDEA which version he was on. Was it even a non-beta version?

Now, I'm not trying to deride the author too badly, but trying make a point. If you're willing to take such undocumented, unsupported information on faith, why not take the word of thousands of happy Subversion users and administrators (not to mention the likes of the Apache project, KDE, and hundreds of others)?

I have managed MANY Subversion repositories over the last couple of years, with glorious success and ZERO complaints -- ALL WITH THE BDB BACK-END. I'm all smiles. I suggest you disregard such poorly-documented FUD. Instead, try actually READING the SVN book, which covers all of these aspects in heavy detail, possibly combined with the SVN users and/or developers mailing lists.

Re:I truly wished they have given a different name

[theguyfromsaturn]

And for another 10 000$ per month the girls also have good "other body parts" on top of the hair. (well not on top, but in addition)

Re:I truly wished they have given a different name

[rednaxel]

Good that you mentioned it. for $50k a year, I'm glad to license them my own version control system, "Rule The Developers With an Iron Fist". It's actually just Subversion and Trac in a box with a pretty logo and some marketing collateral. Plus, a guy with a nice suit and good hair will come and spend two hours explaining things to them in short words and bullet points.

Or they can get the deluxe version for $100k per year, where the guy with good hair will also take them golfing and out to dinner.

It's sad, not funny. Sad, but true.

Platinum support contract

[dubl-u]

I'll put in a purchase order for the $1,000,000 version with the $100,000 per year support contract. That's the version where girls with good hair provide on site support.

Then you should certainly consider the $200,000/yr support contract. Then the on-site tech is an experienced fluffer. Of course, on the paperwork we describe her as a network technician, so that she has a good excuse for spending a lot of time under people's desks straightening their cables.

Re:I truly wished they have given a different name

[Anonymous Coward]

"And for another 10 000$ per month the girls also have good "other body parts" on top of the hair. (well not on top, but in addition)"

So that would put your job title as: "PIMP"....

free software

[Anonymous Coward]

Perforce has handled file renames and atomic commits for years now. I'm just curious why Perforce isn't used more widely, as it sounds like Subversion is just now trying to catch up with where Perforce has been for a long time now.

Perforce is not free software.

Yes, I know about their license for open source projects. But we all have seen what happens when you use a proprietary versioning system on a free software project (Linux kernel).

If you are talking about all types of development efforts in general (including closed source), then yeah, I would much rather be using Perforce than some of the commercial version control systems that really stink (PVCS/Merant and VSS to name two), but Perforce tends to be more expensive than the other commercial versioning systems, and CVS/SVN is better than the less expensive commercial versioning systems.

At my job, we just moved many of our projects from PVCS/Merant (godawful piece of crap) to CVS and we are so much better for it. Renaming in CVS is kinda annoying, but if we ever decide to switch from CVS, a CVS repository can be converted to pretty much anything else without too much trouble.

Subversion VS CVS

[Masq666]

I've seen a lot of projects moving to subversion lately, what are the major advantages Subversion has over CVS.

Re:Subversion VS CVS

[Anonymous Coward]

You can rename files and remove empty directories.

Re:Subversion VS CVS

[/dev/trash]

It has a cool name.

KDE is not the biggest one

[MemoryDragon]

Apache almost switched all of is infrastructure to SVN... if you know that Apache.org is a little bit more than simply the webserver, you know what I mean. Guess the code which already is hosted on the Apache SVN outnumbers the one from the KDE project.

But nevertheless, Konkratulations

Re:KDE is not the biggest one

[Anonymous Coward]

KDE also hosts a bit more than what's are the KDE releases. Do you have any concrete figures like lines of code (old KDE count: over 4 millions), revisions numbers (KDE: over 400000) or size?

Re:KDE is not the biggest one

[MemoryDragon]

Not really concrete figures, but apache hosts following infrastructures: apache jakarta apache-xml

with jakarta alone having more than 30 subprojects many of them in the realm of several million lines of code... so go figure it out yourself.

but besides that, those two big installations clearly show, that subversion really is ready for serious use. All I wished for would be a decent KDE and OSX frontend to SVN, the best would be to have svn integrated into konqueror and getting versioning on vfs level that way, just the way tortoise does it.

Re:KDE is not the biggest one

[Anonymous Coward]

Why do you have problems to come up with figures? I just went to http://svn.apache.org/viewcvs.cgi/ and voila, Apache has only 168000 revisions, less than a half of what KDE has now in the repository (and that's even optimized like same commits to HEAD and branches were merged into one revision).

Re:KDE is not the biggest one

[jpkunst]

All I wished for would be a decent KDE and OSX frontend to SVN

I find this a very usable graphical SVN client for OS X. I mainly use the command line myself, though.

JP

using from past couple of months

[bindaaas]

Trac + subversion (500 Mb repository) is awesome combination. Easy to setup and less to worry about. Best feature is the wiki support from trac where anybody can add to the content. Just love that feature.

Using bbdb as a backend and as mentioned by others, it has issues. Once in a while the repository is corrupted and I have to run svn-admin recover to fix it. Planning to convert the backend to FSFS but am still not sure about its reliability (atleast subversion website says its still beta and not well tested).

this was going off topic

[eille-la]

suggestion for organising your work as a pimp: kde-pimp

CVS or SVN for independent files?

[Anonymous Coward]

SVN is damn cool to use for projects as files and folders are all dependent. Having a global revision number is quite usefull.

But if you have a folder which is not part of a project and where files are independent, for example for some automation scripts, there is no need to have them managed with a global revision number notion. For those situations, it looks like CVS has some advantages.

You can directly see if you have the latest revision of a script (without checking a $LastChangedRev$ value), even if another script has been updated.

Re:I truly wished they have given a different name

[Anonymous Coward]

No, the guy who puts in the purchase order is a john, the salesman with good hair who solicits the purchase order is the pimp.

Kids these days ... they just don't have any experience.

CVS better for independent files?

[Anonymous Coward]

SVN is damn cool to use for projects as files and folders are all dependent. Having a global revision number is quite usefull.

But if you have a folder which is not part of a project and where files are independent, for example for some automation scripts, there is no need to have them managed with a global revision number notion. For those situations, it looks like CVS has some advantages.

You can directly see if you have the latest revision of a script (without checking a $LastChangedRev$ value), even if another script has been updated.

ever heard of making backups?

[toby]

The citation is a red herring. It doesn't matter what format your repository is in, whether you have software issues or not (I haven't seen bdb corrupt anything yet), sooner or later the disk will die. I hope, after going back to CVS, that guy finally realised it is wise to keep backups.

Money quote, as pertaining to VSS:

"Visual SourceSafe? It would be safer to print out all your code, run it through a shredder, and set it on fire."
-Fitz

Re:ever heard of making backups?

[gstein]

The disk could die, or what is worse: drop a bit here or there. Those subtle corruptions are much worse by far. Thankfully, Subversion keeps MD5 checksums of all data in the repository. When it goes to read from the disk, it can detect the corruption and tell you that a problem exists. It can't correct it, but it won't let it silently slide by... We also use checksums over the wire (not all TCP stacks compute checksums). Checksums are also retained on the client to watch for problems there -- generating a diff against a corrupted file produces some very funky results.

Anyways... if the repository gets some bit rot, then you pull out archival backups to see when it blew up. If you're really serious, then you access every file and every revision once a week. Worst case, you'd only need to fix bit rot that occurred in the past week.

This is much nicer than RCS and CVS's silent failure. I know that BK keeps checksums on disk, but I'm not sure about some of the other contemporary systems. They all *should* if you want to consider them to be a production-strength system worthy of storing millions of lines of code for years and years.

Re:ever heard of making backups?

[toby]

Agreed. And what's so hard about a svnadmin verify as a cron job? If the code is valuable, keep a daily rolling backup; svn's ability to hot-dump make it very simple. That's what I do. Disk is impossibly cheap today...

Here's a good question... Microsoft??

[5n3ak3rp1mp]

What VCS does Microsoft use for its own internal development efforts?

If it was Visual SourceSafe, then that might explain some... Windows issues. ;) Internally, we don't call it VSS, we call it SSS (SourceSafe Sux).

It just seems like most of the large-project-oriented VCS's (Perforce, cvs, Subversion, etc.) are open-source.

Re:Here's a good question... Microsoft??

[Anonymous Coward]

AFAIK they use Perforce, which also AFAIK isn't open source, but costs big $$.

Then again, I may be entrely mistaken..

Re:Here's a good question... Microsoft??

[sidecut]

We call it SortaSafe.

We've been using SVN for six months now for a huge VB.NET project. SourceSafe repositories need to be uncorrupted every couple of months, whereas our SVN repository -- at 47MB and counting -- uses BDB and has yet to be corrupted. (Oh great -- I've just jinxed myself.)

Re:Here's a good question... Microsoft??

[MemoryDragon]

Not working at Microsoft, but to my knowledge they used to use Clearcase (I was at a Rational seminar in 99 where they bragged about having Microsoft as customer) but to my knowledge they nowadays use Perforce or some kind of Perforce fork, which is very similar to SVN but is better.

Re:Here's a good question... Microsoft??

[Anonymous Coward]

What VCS does Microsoft use for its own internal development efforts?

You can't realy talk about Microsoft as a whole. Different product teams use different source control systems. The source code for Windows is maintained with a custom system developed by the NT team. It isn't VSS.

Re:I truly wished they have given a different name

[Zaiff Urgulbunger]

And someone do something about the Gimp at the same time please! ;D

How does Subversion compare to Clearcase?

[Anonymous Coward]

At work I use and love Clearcase (really) except that we don't have enough expensive Clearcase licenses. If any of you are Clearcase users who have moved to Subversion, does it have a comparible feature set (labels, config specs, etc)?

Re:How does Subversion compare to Clearcase?

[MemoryDragon]

Actually you must be a clearacase only user, if you ever had to admin it you would hate it. No SVN is not even comparable. While clearcase builds a unix on top of everything before even going into the versioning infrastructure and then adds lots of bloat which most people never will need, SVN just tries to do what a centralized version system does. Clearcase however has the advantage of having a stable repo replication mechanism (which you pay huge dollars for) Subversion is not there yet, there is a project which allows decentralized versioning on top but it is not yet integrated. You wont get some kind of semi working software process like in clearcase, all you can get is a working versioning server and the tools around it. But on the other hand you also dont need a full administration departement to keep things up and running.

Sorry to say that, but Clearcase in 99.999% of all cases is totally versioning system overkill.

Re:I truly wished they have given a different name

[EugeneK]

Call it "Project Manager Server Professional Edition 2005 XT(R)(TM)". Can't lose!

Sure KDE is the biggest!

[zander]

Its easy to say that apache is quite large; but its also quite new and doesn't have such a long history for many of its subprojects.

In fact the kde repository consist of a lot more then the apache repositories both in codelines and history. After conversion its about 220% the amount of revisions.

So; no. You're wrong. KDE is the biggest one by far to adopt svn.

Now lets see if its any good :)

Re:I truly wished they have given a different name

[robertjw]

My managers simply refuse to use anything proposed by us, the development team, and named subversion.

Wow, your managers actually listen to anything your say? Crazy. My manager wouldn't pay attention long enough to actually object.

Re:I truly wished they have given a different name

[CarpetShark]

My advice? Go work for a sane company :)

I think a lot of things in Subversion could be improved, but for a project that is supposed to take the mindshare from a previous tool, subversion is the perfect name, imho. If all open source projects (or even just other version control tools) chose names that well, they'd probably be more successful.

Is KDE using BDB or FSFS?

[lorcha]

Anyone know if KDE is using the BDB or the FSFS backend?

Re:Is KDE using BDB or FSFS?

[stilborne]

FSFS

Re:Is KDE using BDB or FSFS?

[trapni]

I read in the lists (some time ago), that they've had some odd problems using fsfs, and though are using bdb.

I might be wrong here in case I'm not up to date. But that's (been) the state as of reading the lists that day.

Re:I truly wished they have given a different name

[Spoing]

My managers simply refuse to use anything proposed by us, the development team, and named subversion.

You think that's hard...try and get sign off on something called Double Choco Latte!

My manager at the time had this comment; "It's a great program, and exactly what we need, though I can't tell anyone about it here -- they'd laugh in my face! I'm just not going to do it!" In order to 'sell' it to other groups, we renamed it to "DCL" and swapped out the default logo. Nobody laughed, though we weren't complete enough and someone noticed a reference to "Double Choco Latte" and the begining support simply evaporated.

Re:I truly wished they have given a different name

[Spoing]

And someone do something about the Gimp at the same time please! ;D

Sure! (OK, it's not The Gimp with a different name, but it's a damn nice fork with some high end features.)

Just use backports.org, Luke!

[Anonymous Coward]

I've been using Subversion from backports.org on a number of Woody machines for over a year; I've never had any issues with it.

Save yourself the compiling headache, and head over there - you might also find lots of other .deb's you'd like.

Very useful indeed!

[Colol]

Exactly! I love the repository revision numbers for testing purposes. When I build a release, Xcode bumps a plist value to the current repository version, and the users see that as the beta number. I don't have to worry about tagging a "release" in the repository for a beta, and I know exactly what to check out if a bug report comes in.

This is incredibly nice when you may have a half dozen or more different testing builds out at the same time, as I have in the past. It makes it much easier to do little one-off builds to squash one user's bug at a time.

Re:I would love to see how well Insurrection works

[Zaiff Urgulbunger]

Stuffing a server-side XSLT transformation shouldn't be too difficult though, so I don't see this as being a barier.

*lol*

[Anonymous Coward]

> who collaborate through freedesktop.org

*lol*

Great tool, but SLOW on big repos

[BaldBass]

We have switched part of our development to Subversion and are enjoying every moment of it.

...except for the fact that it is very slow on big repositories. How big? I would say 20K files and up.

The bad news is that it doesn't look like this problem is going to be fixed any time soon. It is the design of the workspace (client part) that slows things down -- it creates several additional files per every checked out file and God only knows how many directories. Of course keeping track of these takes very long.

People say, ReiserFS works almost as fast as CVS, but this is not going to help us on Windows :-(

Re:Great tool, but SLOW on big repos

[trapni]

if that .svn dir just scares you; have a look at svk [google might provide the URL] ;)

Re:I truly wished they have given a different name

[js7a]

Maybe the managers are just really, really smart, and are holding out for Arch.

Re:I truly wished they have given a different name

[darkjedi521]

Maybe that had a bad experience with the other DCL

WebSVN is up

[Anonymous Coward]

As of e-mail announcement early this morning.

Re:I would love to see how well Insurrection works

[Anonymous Coward]

The RSS feed from Insurrection now claims that for some known set of browsers that do not support XSLT, it will automatically process the requests differently.

The revision note is at http://svn.sinz.com:8000/log.cgi/Web/?r1=96&r2=96 for those of you who understand what the details mean.