Subversion 1.5.0 Released

Hyrum writes "The Subversion team is proud to announce the release of Subversion 1.5.0, a popular open source version control system. The first new feature release of Subversion in almost 2 years, 1.5.0 contains a number of new improvements and features. A detailed list of changes can be found in the release notes. Among the major new features included in this release is merge tracking—Subversion now keeps track of what changes have been merged where. Source code is available immediately, with various other packages available soon."

Comments

Is it me ....

[Archangel Michael]

or does anyone else find the FISA article and the Subversion article being sequential a tad ironic?

3, 2, 1

[Anonymous Coward]

Cue in the subversion vs git vs cvs vs monotone vs hg flames.

Re:3, 2, 1

[cp.tar]

Those flames are subversive to normal communication, not to mention monotonous. But now that you mentioned them, somebody will have to start one. What a git.

Re:3, 2, 1

[Drinking Bleach]

I never got the (recent?) craze over using the latest SCM of the week myself. If one system works good enough for you right now, why switch? Unless there's some critical feature of SVN/git that CVS has, is it worth the risk of using various conversion scripts (which can and do lose some data in the repository)?

I mean, OpenBSD has stated in the past that CVS works well enough for them, and the risk of converting the repository is not worth it just for some newer system. In fact, it's partially behind the motivation to develop OpenCVS....

Re:3, 2, 1

[cduffy]

Part of the problem is that the conversion scripts coming from CVS have to make up some data that isn't in the repository, but which all newer SCMs track.

If you get yourself to something modern enough to support multi-file transactions, to recognize rename operations, to store merge history, and to manage branches in a reliable way (creating a file on a branch in CVS can also create that file in HEAD... or at least, it did last time I used CVS in production) future conversions won't be as necessarily painful and/or lossy.

CVS isn't even reliable in terms of storing history in such a way that you can guarantee that you haven't lost something; when I was maintainer of cscvs, I had several users having problems because their ,v files had gotten truncated somewhere way back; because that only impacted attempts to retrieve revisions prior to the truncation point, nobody noticed until their backups had already been fully rotated past that point. More modern SCMs have provisions in their data formats for validating repository validity, and even for checking changesets against deliberate tampering.

If you're legitimately concerned about your data, you'll get off of CVS at the first opportunity.

Re:3, 2, 1

[Anonymous Coed]

What a bazaar reply. Are you suffering from mercurial poisoning?

Re:3, 2, 1

[johannesg]

I never got the (recent?) craze over using the latest SCM of the week myself. Dude, SVN is ***EIGHT YEARS*** old. It is hardly the craze of the week.

If one system works good enough for you right now, why switch? True. But what if it sucks, why keep telling yourself that it is really great? Because that's the problem with CVS: it really isn't all that great.

I mean, OpenBSD has stated in the past that CVS works well enough for them, and the risk of converting the repository is not worth it just for some newer system. In fact, it's partially behind the motivation to develop OpenCVS.... Oh well, if *Theo* said that then it is ok...

Re:3, 2, 1

[smittyoneeach]

Probably. I'll head down to CVS before it gets too darcs and see if I can pick up something. Oh, and a quilt to keep the patient warm.

Re:3, 2, 1

[Drinking Bleach]

> Dude, SVN is ***EIGHT YEARS*** old. It is hardly the craze of the week.
It was more of a response to the parent, than the article. I use SVN myself for a few projects... even started off a new repository on SVN.

> True. But what if it sucks, why keep telling yourself that it is really great? Because that's the problem with CVS: it really isn't all that great.
I never said to keep telling {my|your}self that CVS is really great, but I said *if it's good enough*. Unless there's really a mission-critical feature in the newer SCMs, there's hardly a reason to switch.

> Oh well, if *Theo* said that then it is ok...
Actually, it was Ray Lai.

Re:3, 2, 1

[truthsearch]

CVS was good enough for my company until we learned how SVN was able to make many things much easier. We did fresh imports of all of our projects into SVN. So we lost history in the new repository but kept around the old CVS repository just in case we needed its history.

That was a few years ago and we're far more productive today, especially with branching and merging.

Re:3, 2, 1

[Qbertino]

You guys are really trying to be funny by perforce.

Re:3, 2, 1

[nonsequitor]

I'm in the process of migrating my department from Subversion to Git for a single very compelling reason. Distributed Development.

I work in the Maritime Industry and frequently have to change software on the fly during Sea Trials. With SVN, revision control while on a boat is impossible since while offline, there is no access to the central repository to check in revisions. Now with Git, I can continue to work productively offline and seamlessly push the day's changes and revision history to a repository on the network drive for nightly backup when returning to the office.

I realize not everyone has the requirements I do for source control, but everyone should pick the SCM Tool which best meets their organization's or personal requirements. Having a working familiarity with several tools is necessary to make an informed decision.

Re:3, 2, 1

[Anonymous Coward]

Subversion sucks! VSS FTW!

Re:3, 2, 1

[John Whitley]

I never got the (recent?) craze over using the latest SCM of the week myself. For those of us who really understand SCM systems, and are heavy users of same, the desire is to get a handle on the capabilities of the new generation systems. The reason is simple: CVS utterly sucks, and SVN wasn't a revolutionary improvement. Simple high-level tasks in a real working environment (e.g. tracking upstream branches against local changes) are frequently a time-consuming pain. Many collaboration use cases (e.g. developer/feature branches) are similarly a hassle to manage. SVN at least gave folks atomic commits, which was a huge step.

My guess is that SVN will turn out to be too little, too late with its merge tracking support. It'll be a boost for folks already using SVN who don't want to switch toolchains, but it's pretty easy to move from SVN to the new tools (beyond export, several newer SCMs have two-way commit support with SVN).

Generationally speaking, it feels like SVN is still trying to catch up to Perforce... but that ship has sailed. The teams working on the new round of decentralized SCMs[*] have done deep rethinking of source control problems and challenges, and the results are generally brilliant. These problems aren't esoteric -- administration and day-to-day usage really is easier with the new stuff. After a while using git, Bazaar, etc., the crufty old SCM tools seem like doing image editing in a hex editor instead of a GUI app.

[*] Includes: Bazaar, Darcs, git, and Mercurial (hg)

Re:3, 2, 1

[smallfries]

That's interesting. I was thinking of making the same change recently. Most of the subversion repositories that I use are either single user or only a small number, so the distributed nature of giu didn't appeal for the normal reasons.

But after a trip away without an internet connection I realised that not being able to take the repository with me and then handle merges when I got back was a bit of a limitation. Git looks interesting because it would get around this issue... but I just spent some time hacking up a tool to merge dumpfiles in the correct date order for revisions. If it works out I may just use it to keep a mirror of the repository on my laptop and merge it back in when necessary. Never upgrade your tools unless you really need to... :)

Re:3, 2, 1

[Just Some Guy]

With SVN, revision control while on a boat is impossible since while offline, there is no access to the central repository to check in revisions. Now with Git, I can continue to work productively offline and seamlessly push the day's changes and revision history to a repository on the network drive for nightly backup when returning to the office.

Having not used git before, I don't really see what's so great about that. Suppose that your code is in svn in branches/devel. You could do a nightly svn cp branches/devel branches/`date +%Y-%m-%d` to track all your revisions locally. You can do diffs between branches, delete them, rename them, etc.

Again, I've not used git. What would it do better? Help me see the light.

Re:3, 2, 1

[JesseMcDonald]

There's also Mercurial, which maintains a command syntax similar to Subversion, but uses distributed repositories. With it one can easily create a local repository suitable for offline use, including access to the full project history.

Re:3, 2, 1

[R_Dorothy]

You don't have to do a nightly svn cp branches/devel branches/`date +%Y-%m-%d` to track all your revisions locally.

Seriously though, each working copy is a fully functional repository with complete history able to merge changes from other working copies (which are also fully functional repositories etc.)

It also doesn't need a full server infrastructure. I've started using local, stand alone, git repositories to track config files.

Re:3, 2, 1

[eison]

Subversion stores merge history? Where? If it does, why do the instructions tell you to manually track the merge revision numbers yourself? http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.1

This is the one thing that really annoys me about subversion - it is seriously missing some key bookkeeping here. Yes, I know there are scripts that hack it in, but that's not the same as doing it right in the first place.

Re:3, 2, 1

[WuphonsReach]

Dude, SVN is ***EIGHT YEARS*** old. It is hardly the craze of the week.

Just one minor point of note, at least for our experience. It may be 8 years old, but it really wasn't suitable for our use until 1.3 (and we waited until 1.4 was done to actually do our rollout).

We wanted to use it earlier (started looking at it back in the pre-1.0 days), but we didn't switch until 2006. Shortly after the 1.4 release.

Re:3, 2, 1

[cduffy]

Subversion stores merge history?

As of 1.5, yes. That's one of the Big Features for this release.

Re:3, 2, 1

[WuphonsReach]

I suspect if we ever switch away from SVN, Mercurial is a strong contender.

But for us, we don't currently place a high value on distributed and decentralized. Mostly because it's easier to be constantly connected then it was 5 years ago, but also because our users are not especially technically inclined.

Getting them to understand update/check-in and keeping their local disk in sync with the server is challenging enough (even with TortoiseSVN).

The other strong selling point for us is the broad adoption of SVN across multiple platforms and that it works with a lot of different tools. Combine that with being actively developed and improved, and it's head and shoulders above what we used before.

(Note: We don't do a lot of branching and merging. We're more excited about sparse checkouts.)

Re:3, 2, 1

[edalytical]

This had better stop before we end up Arch enemies.

Re:3, 2, 1

[complete loony]

I'm not going to say git is a poor choice, far from it. However if you ever need disconnected svn access have a look at svk. It provides a local mirror and local branches off a central repository with merge processes to update them in both directions. Though its interface probably needs a little work.

Re:3, 2, 1

[Anonymous Coward]

why do the instructions tell you to manually track the merge revision numbers yourself? http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.1

Because the instructions you quote are for SVN 1.1.

Re:3, 2, 1

[Anonymous Coward]

It's too little, too late. Git has already surpassed svn in every respect that matters.

I note the preliminary merge support with interest, because we use svn at work (and I'm encouraging conversion to git) and having svn's metadata showing merging some of our branches will help with the conversion to git.

Re:3, 2, 1

[cduffy]

I agree with you that this is too little, too late. That said, there's one respect where Git is well behind: Usability.

svn and bzr both have it beat -- hard -- in that respect; particularly svn, which has more pervasive tool support (but plenty of other disadvantages). That does little good, though, when you're picking a tool for use on a large project including artists, tech writers, win32 GUI developers, and other folks who have less of the appropriate inclinations.

I say this as someone using git on a daily basis. It's not a bad tool, but an end-all be-all it's not; for my own projects, I use bazaar.

Re:3, 2, 1

[Anonymous Coward]

Read the URL you just posted. That's the Subversion 1.1 documentation which is waay old.

Re:3, 2, 1

[nonsequitor]

We've only been using SVN for the last 8 months, so switching SCM's is not a huge ordeal right now. To be honest I'm quite happy with Git so far. There's only a handful of developers at my company so we don't have time to become experts with any tool, and as far as basic features goes, Git works in a way which fits our development paradigm better.

To be fair, with different requirements I'd use Subversion again in a second.

Re:3, 2, 1

[Scullywag]

This is a clearcase of a thread going out of control.

Re:3, 2, 1

[Anonymous Coward]

Right, because remembering a bunch of svn:properties is so easy. Figuring out why subversion memory faults when given both a file and url path is so user friendly. Or why you can't use a subversion folder through a symbolic link. Or why there are .svn folder everywhere, or if they are hidden why you can't remove an empty folder. etc. svn is a piece of junk and especially from usability pov.

In this release they made it so you can mark a subfolder so it doesn't update automatically. That's like two lines of code.... noup = get_property(curpath, "noupdate"); if (matches(noup, "nosubfolder")) return; That's the big progress they've made on the file layout which they've known for years is retarded ?!

In mercurial or git people submit patches for this kind of thing all the time, because it's in python or scripts and easy to change. Svn is over-engineered and so inflexible that it is being left behind.

Re:3, 2, 1

[Anonymous Coward]

I'm not talking about usability by power users; I'm talking about usability by idiots. Think Windows, not vi; both of those are very usable, but by two different groups of people. Compared to git, svn has a comparatively simple set of concepts which need to be grasped by its userbase. Yes, the WC library is horrid, and has all kinds of nasty gotchas that hit command line users -- particularly around renames, but your average idiot is coming from CVS (if anything at all) and doesn't expect renames to work anyhow.

I agree that svn is a POS. I've always thought that, and if you look back a bit in my posting history you'll see it confirmed; however, in a commercial environment it's often an easier sell than git.

Re:3, 2, 1

[renegadesx]

Just shows this thread requires git

Re:3, 2, 1

[MadKeithV]

But is anyone keeping the source safe?

Re:3, 2, 1

[Anonymous Coward]

SubVersion doesn't need a server. It can access repositories directly using the file:// "protocol".

Re:3, 2, 1

[Anonymous Coward]

you better git going.

Re:3, 2, 1

[Necronomicode]

This is a ClearCase of joke gone too far.

Re:3, 2, 1

[tucuxi]

Stupid gits!

Re:3, 2, 1

[stsp]

The teams working on the new round of decentralized SCMs[*] have done deep rethinking of source control problems and challenges, and the results are generally brilliant. These problems aren't esoteric -- administration and day-to-day usage really is easier with the new stuff. After a while using git, Bazaar, etc., the crufty old SCM tools seem like doing image editing in a hex editor instead of a GUI app.

You're painting this far too black and white.

Distributed systems have their own set of limitations, some of which centralized tools don't have. Some development processes cannot be implemented with distributed tools, pretty much the same way as processes such as how the Linux kernel is developed cannot be implemented by centralized tools.

For example:

Let's say I wanted to make sure that any change going into my project enters the main line, or "trunk", first, and is then applied to release branches if necessary. This makes sure that I have one common place to log all changes ever entering my code base. That's very simple requirement, right? This approach is used by many projects, e.g. by all the BSDs, and by Subversion itself. Let's say I picked Mercurial as my tool for the job.

So I have a changeset on my trunk, and I want to merge it into my 1.x and my 2.x release branches. I will first need to pull the change from trunk into my branch, right?

hg pull [-u] [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [SOURCE]
-r --rev a specific revision up to which you would like to pull

Wait... why does it say "up to which"? I just want that one change!

Darn, turns out that in Mercurial, changesets depend on all their ancestors in order to guarantee integrity of all changes I pull from another clone of my repo. You cannot pull a change without having around its parent, since revisions are identified by hashes in order to be globally unique across all clones. The hash of a revision is derived partly from the hashes of its parent revisions (they are included in the manifest).

So I need all parent revisions of my changeset in my branch. Since I've forked off my branch from trunk, and have not yet made changes to the branch itself (remember that all changes to the branch should be coming in via trunk), Mercurial will see no conflicting heads and simply forward my release branch to the latest head of trunk. So I can either pull every change I've made on trunk since forking the release branch (not much point in that), or manually apply a patch to the release branch (i.e. side-step the tool).

Well, great. With Subversion 1.5, all you need to do to get a changeset, say rev 42, from trunk to a release branch is

cd branch-working-copy
svn merge -c42 http://url-to-trunk/

So in practice, people using Mercurial end up fixing problems on their release branches, and merge the fixes to their main line later. And yes, it seems like you have to manually apply a fix to all your release branches separately (at least I haven't yet found another way).

In all fairness, there is in fact an extension that allows Mercurial to "transplant" a changeset from one branch to another without requiring you to also merge all the parents of the changeset: http://www.selenic.com/mercurial/wiki/index.cgi/TransplantExtension

This extension maintains a special file mapping local changeset hashes to remote ones. You have to bet your luck on not ever creating the same hash for two different revisions, though, otherwise your project's history is borked (I have no idea how likely this is).

Certainly, maintaining a separate list of changeset ids is not something intended in the original design, which focused on providing distributed branching and merging. The design does a very good job at this no doubt. By making sure that all bran

Re:3, 2, 1

[godefroi]

We've been using it since 0.27. Been great.

Re:3, 2, 1

[IkeTo]

I've always been using Subversion, but always see that as a serious limitation that makes it very tempting to seek an alternative. (But then, nothing else is as commonly available as Subversion, detering that switch since I need to work on many machines that I have no administrative rights.)

The story line is something like this. I have a program (or whatever that need history kept) that I collaborate with others, I create a repository and put it into the Internet so that others can access. Now I work at both office and at home, and for cost reasons I don't have an Internet connection at home. But from time to time I need to work from home. Then I have a problem: how I keep history for the work I do at home, given that I have no Internet access?

I can, of course, keep different versions at different directories. But it is pain to merge them back once I'm online. I can, of course, forget about history keeping. But if something happen I have nothing good to fall-back onto and I have no choice but to debug (normally I can choose to throw away what I've done and start again); and of course I'll give the person reading my change a really hard time when I merge everything back. I can also keep it in a local repo, which is somewhat better but needs time to setup and still difficult to merge with the actual repo that others are using. Most of the time, I end up giving up and wait until I'm online before I work.

I think this is expressedly not a use-case that Subversion will look at. It is a centralized VC scheme, and if one want distributed VC one has to look elsewhere. Perhaps svk, or perhaps arch/git. The unlucky fact is that no other system is as popular as Subversion (and of course, CVS).

Re:3, 2, 1

[Just Some Guy]

Could you do something like using branches in place of commits, then when you get back online merge each of those branches in turn back onto the original tree?

Hmmm. I'm starting to see the appeal of git et al.

Re:3, 2, 1

[isham]

Let's be Rational about this.

Re:3, 2, 1

[ckaminski]

SVK. I do have a few problems with the way SVN/SVK works and the way I want to use it...

But I love it for distributed development.

Re:3, 2, 1

[ckaminski]

May I suggest SVK?

I do this with my webserver, synced to my master repository (push from home), my laptop, my office (pushed to webserver), then sync'd back to the master.

It's not seamless, but I see that SVK/git has motivated the SVN team to make adjunct tools like this easier to integrate with SVN.

Re:3, 2, 1

[telbij]

however, in a commercial environment it's often an easier sell than git.

Agreed. Now remind me never to ever work in such an environment again.

Re:3, 2, 1

[Anonymous Coward]

Why not use a local svn repository in addition to the central repository and 'svn switch' between the two?

I used to do that when I was using a laptop that only had occasional network access. You lose the granularity of the commits you've made while away from the network, but you don't sacrifice revision control while you're isolated.

Re:3, 2, 1

[nonsequitor]

Thanks, I'll look into it. I haven't gotten rid of the SVN repository yet, in fact we were planning on keeping it live for the next year, just in case.

Re:3, 2, 1

[IkeTo]

Yes, but again, it's painful to do if it happens often. What I'd have to do is (1) go home with my working directory, (2) create a repo for it, (3) start working on it with the repo, (4) (once online again) find the revision number that has the version I *was* having when I start working offline, (5) create a branch, (6) start pains-takingly update to each of the version I've created and check in, and finally (7) merge the result to the mainline. And even after that pain it is hard to see my history in the mainline, it looks as if a big portion of code has been modified in a single revision, and my only way to know the actual small steps taken is to have a log message saying "merge from branch xxx" and look at the branch xxx for each step. Not ideal at all for me.

Re:3, 2, 1

[cduffy]

Perhaps svk, or perhaps arch/git.

Heh -- it's been a while since I've seen Arch mentioned anywhere.

Tom Lord abandoned it, and most of the other core people jumped ship to Bazaar (and are now working for Canonical). Bazaar, as a result, has been extremely cautious not to make the same mistake, and focused on usability early in its development; I think it's come out to be a stronger project as a result.

Incidentally, bazaar has a Subversion plugin available; with that installed, SVK's interoperability with SVN becomes significantly less unique.

Re:3, 2, 1

[ckaminski]

Problems come from when you try to have two peer "master" repositories. I'm still having trouble working out the workflow issues around that. I have some web-based master repositories that I clone to my home PC (master master?), and some private repositories that I don't publish to the web for commercial work. I'm so invested in SVN and the great toolchain build around it (Tortoise, etc) I'm not interested in moving. It would be great if it was library-ized so other tools could use it. :-/

Re:3, 2, 1

[IkeTo]

As I said, I know there is svk, and other distributed VC systems. The problem is just that nobody "win" in that area yet, so nobody get all the market share. System admins (especially those working in CS department of universities) tends not to install the needed software in those cases, and tell users to do it themselves (even though that means they have have to deal with the dependency hell themselves).

Re:3, 2, 1

[cduffy]

I don't think your example is representative of the field: "A one-size-fits-all version control tool with a design that needs no hacks to make it work with any given development model" is exactly what Bazaar is intended to be.

Light checkouts and bound braches allow it to operate much like a traditional centralized SCM (with varying levels of space and bandwidth tradeoff), while its distributed operation provides all the available workflows of that model.

Re:3, 2, 1

[RAMMS EIN]

``I mean, OpenBSD has stated in the past that CVS works well enough for them, and the risk of converting the repository is not worth it''

It may be good enough for them, but it's not good enough for me. I don't want to spend half a day upgrading my ports collection through CVS if it's quicker for me to just download the new tarball.

``I never got the (recent?) craze over using the latest SCM of the week''

I think it is recent mainly because Subversion has broken the hegemony of CVS. Of course there is much inertia to switch, and that is a Good Thing. Subversion, however, is easy to pick up and so much better that it actually displaced CVS as the Version Control System Everyone Uses (TM). Inspired by the success of Subversion, everyone with the inclination and a large enough ego started their own "better than CVS" version control system. Some of them are horrible, some of them are shiny commercial crap, some of them are better in theory, but lacking in implementation, and some are actually better. My personal favorite is Git. It works well, is easy to pick up if you already know CVS or Subversion, has a couple of desireable features, and, last but not least, it's FAST. Of course, many people will stick with Subversion, CVS, or whatever Microsoft integrates with their other software.

Re:3, 2, 1

[RAMMS EIN]

I'll add to your post a point that is often missed, so it bears repeating:

Just because git _allows_ you to do distributed development (multiple repositories) doesn't mean you _can't_ have a single main repository. There can still be one "blessed" version of the code, which is backed up and everything else you like to do with your Subversion repository.

However, if you ever want to make a couple of commits while disconnected from the network, or try something out, making multiple commits along the way, until you can make an informed decision about pushing your changes to the main branch or not - with git, you can. So, even if you don't need those capabilities now, choosing git may still be a good idea.

Re:3, 2, 1

[nonsequitor]

I avoided calling it a Central Repository in all the training materials I prepared for my coworkers, instead I called it the Authorative Repository. Only a small subset of us have write access to it, so no one can push any branches to it. Instead, approved changes must be pulled to it by myself or the other maintainer, but everyone can read from it if they want to create a remote tracking branch or pull from it. Push was only implemented to allow those familiar with a central repository paradigm to keep the same workflow, it's not a necessary function to work with Git.

The authorative repository is the only one releases will be made from, though since everyone's working repositories are on network drives they are all backed up nightly. Then if they are working offline, they just clone their personal working repository to a local drive. I really like that I can pick and choose which repositories to merge based on the fix or feature, and have the developer working on those branches be able to pull from the authorative repository in the mean time to keep the branch from diverging too far. Maybe something similar can be done with SVN, but I really like how the Git paradigm fits, and even encourages, that workflow.

Re:3, 2, 1

[nonsequitor]

I believe Git solves this problem by using a completely different paradigm. Git does not use sequential revision ID's, instead the ID is a SHA1 hash of the contents of the repository. This allows all clones to be equal and still merge branches across repositories without messing up the workflow, if I understand it correctly.

A result of this is that individual repositories can have different histories, but when they converge, the revision ID's match up. I also love the feature of being able to digitally sign a tag with a gpg key. I don't claim to be at all an expert at SVN, quite the opposite, its just the basic features of Git fit my development model better than the basic features of SVN.

Re:3, 2, 1

[Anonymous Coward]

Let's commit to ending this nonsense

Re:3, 2, 1

[Anonymous Coward]

Some development processes cannot be implemented with distributed tools ... Let's say I wanted to make sure that any change going into my project enters the main line, or "trunk", first, and is then applied to release branches if necessary. ... With Subversion 1.5, all you need to do to get a changeset, say rev 42, from trunk to a release branch is ... in Mercurial, changesets depend on all their ancestors in order to guarantee integrity of all changes I pull from another clone of my repo. You cannot pull a change without having around its parent, since revisions are identified by hashes in order to be globally unique across all clones. Christ. You subversion developers are so wordy. Just like your code.

The process you are setting up is a straw man. You really are going to apply a patch without thinking to every release version? You're going to develop a patch on trunk, which may not even have the bug then apply it to the release? That's insanity. Also, a more realistic revision number is say 10947... "42" makes it sound like revision numbers are useful references when in practice they are no better than hashes. So you need to have extra hashes in your repository... who cares? It's not like subversion developers are caring about using up extra space *cough* *.svn* *cough* anyway.

Seriously, adapt or die. Git and mercurial are destroying svn in the market. Oh yeah, and do no evil bro.

Re:3, 2, 1

[corrie]

git off my lawn!

Re:3, 2, 1

[jgrahn]

Subversion stores merge history?

As of 1.5, yes. That's one of the Big Features for this release.

It is also the Big Feature which the SVN fans have promised pretty much since the project started. It's probably the feature I miss the most in CVS.

I'm happy that they have made it work. Now let's see if people will start to use it in practice (i.e. branch more frequently).

Re:3, 2, 1

[Anonymous Coward]

I hope the bitkeeper does his work

Re:3, 2, 1

[Anonymous Coward]

But is anyone keeping the source safe?

The starteam is supposed to be in charge of that.

err...

[Anonymous Coward]

I think it's you.

I'm just happy it's finally released. First feature release in two years!

I disagree with Linus on this one

[Anonymous Coward]

If git is so much better, why doesn't linux support dtrace and zfs yet?

Re:I disagree with Linus on this one

[Anonymous Coward]

Patent and licensing issues, idiot.

As an Irish-American

[$RANDOMLUSER]

I'm more into sedition than subversion.

Wait. What?

Re:As an Irish-American

[Anonymous Coward]

Dear Irish-American,

Please stop giving us a bad name by being a dick

Sincerely,
An Irish Irish

First release in two years ?

[Kingston]

Sounds like they need to use some sort of version control system to help speed things up.

Re:First release in two years ?

[Anonymous Coward]

Oh, the 1.5 branch was finished for a long time... they just couldn't figure out the right svn command to merge the changes back into the trunk to create the release. *rimshot*

Upgrade breaks working copy compatibility

[againjj]

There is an important piece that is going to keep me from being able to use it for a while:

Before upgrading to 1.5.0, please take note of the following: * Due to various improvements made to the working copy library, the working copy format has changed. Using Subversion 1.5.0 on any working copy created by previous versions of Subversion will SILENTLY upgrade your working copy, which means that previous versions of Subversion will no longer be able to read it. I use multiple clients on my machine, and they all are going to need to be able to use 1.5 before any of them can.

Re:Upgrade breaks working copy compatibility

[Dahan]

There is an important piece that is going to keep me from being able to use it for a while

Subclipse 1.4.0, which works with Subversion 1.5.0 has been released. TortoiseSVN release candidates that are compatible with SVN 1.5 have been out for a while, and the plan is to release TortoiseSVN 1.5.0 this weekend.

Those (along with the SVN commandline client) are probably the most popular clients, so most people won't need to wait "a while".

Re:Upgrade breaks working copy compatibility

[lagfest]

It's only a problem if multiple clients have direct access to the repository files. If your repository is accessed through svnserve or apache webdav, then it's not a problem.

Re:Upgrade breaks working copy compatibility

[smallfries]

Out of interest, why do you use multiple clients on the same working copy? Isn't that somewhat unusual?

Re:Upgrade breaks working copy compatibility

[R_Dorothy]

Different clients have different strengths. I use the command line client for general use but find RapidSVN is generally easier for looking at history.

Re:Upgrade breaks working copy compatibility

[EvanED]

Another fairly common operation under Windows is using both the command line SVN client and Tortoise.

Re:Upgrade breaks working copy compatibility

[Anonymous Coward]

Not unusual at all. Most IDEs have support through plugins now, there's the normal command line client, and many windows users have TortoiseSVN - all of these could potentially be using different versions of the underlying libraries.

Re:Upgrade breaks working copy compatibility

[WuphonsReach]

Out of interest, why do you use multiple clients on the same working copy? Isn't that somewhat unusual?

Absolutely not unusual. I use both the SVN command line client and TortoiseSVN's client on my windows boxes.

TSVN is great for working with individual files and doing the normal tasks of updating a single directory, or checking in files, or doing diffs, browsing the repository, or looking at change logs. Basically, we use TSVN for all of the interactive grunt work that goes on during our normal working day.

The SVN command line client, OTOH, is great for scripted things. Like running "svn update" on all of my working copies at 2am overnight - so that I have the latest changes from everyone else when I start working in the morning. If anyone added huge bulky files to the repository yesterday, they get downloaded overnight without my having to wait. And it speeds things up the next day so that when I use TSVN update, odds are good that I'll already have the latest revisions on my hard disk.

The change in working copy also happened when SVN went from 1.3 to 1.4 - so it's not a new issue. We all had to wait for our tools to be compatible with 1.4 back then as well. I think there were also changes on server-side back then, so if the server spoke 1.4, you had to use a 1.4 client. But you could leave the server at 1.3 and use 1.4 clients (backwards compatible), and then upgrade the server to 1.4 once you were done with client upgrades.

Re:Upgrade breaks working copy compatibility

[againjj]

Subversive since I use Eclipse for the Java half of our app, TortoiseSVN since that is what everyone else in my office uses, Cygwin's svn since I have Cygwin (which is because I miss the Linux command line), and the ordinary Windows command line version since I couldn't get Cygwin's svn to work with svnAnt.

Re:Upgrade breaks working copy compatibility

[JebusIsLord]

I use AnkhSVN (Visual studio plugin) plus the CLI executable.

Re:Upgrade breaks working copy compatibility

[againjj]

I actually use Subversive, since it is an incubating Eclipse project. However, I may switch to Subclipse if Subversive keeps being sluggish. Also, I tend to be rather conservative about tools upgrades, which means that I often wait for a shaking out period before upgrading, and I certainly don't use release candidates. :-)

Re:Upgrade breaks working copy compatibility

[Ed Avis]

Only if the different clients operate on the same working copy. If you have a different working copy (checkout) for each client you're fine. The repository is not auto-upgraded.

Re:Upgrade breaks working copy compatibility

[Reality Master 201]

I do it where I work because we have a deeply shitty IT staff that can't maintain equivalent versions of software across machines (or perform software upgrades unless they cause immediate havoc - we're still running Firefox 1.5).

Re:Upgrade breaks working copy compatibility

[Michael Wardle]

That wasn't the case the last time the working copy format was upgraded. Are you sure?

Re:Upgrade breaks working copy compatibility

[Michael Wardle]

The working copy might be shared over NFS.

You might be dual booting between different Linux installations and sharing your /home directory.

Re:Upgrade breaks working copy compatibility

[lagfest]

I'm sorry, I confused working copy with repository. GP is correct, and I would be, too, if he was writing about the repository, which he wasn't.

Subversion is excellent!

[ozzee]

Kudos to the subversion team. The merge and slave sync features are really great.

I've been using subversion since it first came out and I must say it is really easy to use and a dream compared to some of the commercial offerings I have to fight with.

Thanks for all the hard work...

FreeBSD

[Anonymous Coward]

FreeBSD has been moving to Subversion recently. The change will take some time to consolidate but I am sure they made the right choice due to the way they work.

Does [git/hg/bzr/etc] write my code yet?

[slyborg]

No.

I started out in version control with SCCS. I used the first generation of ClearCase when it came out. (Still the most transparent system yet devised, a dream to use for an individual developer, crippled by inability to scale, admin complexity, and absurd cost).

The fact of the matter is that CVS works. My current project has > 500K lines of code in CVS, and we sell product. We don't like CVS, we're planning to move to SVN, but the fact of the matter is that we don't *have* to. To me, the source control system is more or less like the file system : I need it to the extent that my work is in there, but other than that I don't want to see it or even know it's there. People drool over git and mercurial like these things are -doing work-. I don't get it and I don't buy it. The fact of the matter is, that unlike say a compiler, the SCM system has ZERO effect on the end product.

So I get the advantages -for some projects-, esp. large open source or distributed commercial projects, of a natively distributed SCM system. I don't get how SVN is now inferior and lame because it isn't distributed.

Re:Does [git/hg/bzr/etc] write my code yet?

[chthon]

Ha, here we are using Continuus. Untransparant, unable to scale, administrative nightmare, too costly (in terms of hardware and licenses) and too slow.

Has anybody here experience with svn/git/bzr/mercurial for about 50 developers and a source code tree of 6 Gb ?

Re:Does [git/hg/bzr/etc] write my code yet?

[cryptoluddite]

You don't want to use svn with a large tree because it stores a second copy of only the revision you checked out (so that diffs are fast). Other systems like hg can typically store the entire repository, giving you access to all revisions, in less space (it's compressed) than svn can store just the working copy.

Furthermore, this second copy is stored in the same folder tree, which is both annoying (from a tools pov, like grep) and slow (OS has to stat a lot more inodes).

Re:Does [git/hg/bzr/etc] write my code yet?

[WuphonsReach]

You don't want to use svn with a large tree because it stores a second copy of only the revision you checked out (so that diffs are fast). Other systems like hg can typically store the entire repository, giving you access to all revisions, in less space (it's compressed) than svn can store just the working copy.

SVN works fine with large trees (whether that's measured as # of revisions, # of files, or # of bytes).

Yes, the working copy stores a "pristine" copy in the .svn folder for easy diffs. Which was designed to reduce the amount of server traffic. I'll agree that sometimes that's not always a good choice, but (for the most part) local disk space is inexpensive and the 2x space requirement on the local disk doesn't bother me.

There's been some talk about allowing the user to tell SVN (and tools built on top of the SVN libraries) that there may not always be a pristine local copy. The question, I think, is whether it could be done without breaking other design goals (the ability to be a WebDAV source comes to mind). Or without generating huge amounts of traffic (the anti-argument here is that if rsync can do it, svnserve should be able to).

I think there's also talk of putting the .svn folder in the root of the working copy and nowhere else.

But yes, I'm hoping that they'll switch to storing the pristine local copy in compressed format, which would save a good bit of space. I suspect the design was designed to be conservative with regards to beating on the CPU, and that there were a zillion other priorities to get working first. It's only been in the past year or two that I've seen more frequent mentions of improving the working copy design.

(Being able to have sparse checkouts will probably help us a lot with the local working copy size. It will at least make a dent in it.)

Re:Does [git/hg/bzr/etc] write my code yet?

[WuphonsReach]

You first need to decide whether you want a centralized model, like SVN, or a distributed model (git / mercurial / bzr?). And also consider tool support (SVN has very good tool support, others may not and require more hacking at a command line).

All of the products listed will handle 50 developers and 6 GB of source with no issues. Our biggest repository weighs in at 11GB with a few thousand revisions. Then we have repositories that are only 2GB, but with 50,000 revisions. Sometimes it's nice to have a monolithic repository (ease of use for less technical users), other times repositories for each project are better.

There are other advantages / disadvantages to each version control system.

Re:Does [git/hg/bzr/etc] write my code yet?

[John Whitley]

You first need to decide whether you want a centralized model, like SVN, or a distributed model (git / mercurial / bzr?). Only in that the new tools will support BOTH decentralized and centralized usage, while the old tools only support centralized workflows. Individual SCMs have varying support for some specialized kinds of centralized use cases (e.g. you may need to deploy an extra tool to guard commits to the central repository through integration build/test machines, etc.), but generally work fine and with the added advantages the new tools provide.

Re:Does [git/hg/bzr/etc] write my code yet?

[John Whitley]

In every organization I've worked in, developers have to manage source. Their own source, third-party source (whether OSS, vendor code, drops from another team, etc.) I.e. their work involves more than just blindly pounding out code. The new tools really do reduce the amount of time spent screwing around with the SCM system instead of doing other things. Even really basic stuff like just having more intelligent history-based merging algorithms can save staggering amounts of time.

Re:Does [git/hg/bzr/etc] write my code yet?

[Anonymous Coward]

Yes, the working copy stores a "pristine" copy in the .svn folder for easy diffs. Which was designed to reduce the amount of server traffic. But the only server traffic it reduces is "diff" and "revert". Status can easily be done with timestamps and hashes. Revert happens very rarely and if it were to be slow the user could just as well cp -r to make a temp working copy that can be blown away. In the typical case, diff is on a small amount of source and maybe some binary files (where all you care about is if it differs). So no benefit there either. It's a bad solution for a non-problem.

I'll agree that sometimes that's not always a good choice, but (for the most part) local disk space is inexpensive and the 2x space requirement on the local disk doesn't bother me. It's more the fact that you need to add "|grep -v .svn" so often. And the extra 11 inodes per folder and two extra inodes per file. If you don't have enough main memory to fit these inodes then some svn operations get really, really slow.
.
The svn folder structure has so many negatives I wonder what kind of developers would use that approach in the first place and further what kind would keep using it for a decade.

Re:Does [git/hg/bzr/etc] write my code yet?

[RAMMS EIN]

``People drool over git and mercurial like these things are -doing work-.''

But they do. They keep track of what changed, when it changed, what else changed at the same time, how the change was justified, and who changed it, and, very importantly, how things were before the change.

The choice you have is between having this information and not having it, and between various interfaces to the information.

That's as far as the work they do for you is concerned.

On the other side of the balance, you get to choose your limitations and performance impact.

Of the major systems, I find that CVS has both the lowest performance and the worst limitations, Subversion does acceptably on both counts, and Git has great performance and flexibility.

To sum it up, version control systems _do_ actually do work for you, and there are noticeable differences between them that make choosing wisely worthwhile.

very nice

[Anonymous Coward]

Of course, I've long since converted everything to git, but at least it's nice to know if I'm stuck using Subversion it has at least some basic functionality. (Yes I'm damning with faint praise here.)

Now how about some real tags instead of "branches you don't update"?

Re:very nice

[ckaminski]

Seriously, is that something worth arguing about???

#1 svn feature is, and has always been...

[mike260]

...TortoiseSVN (yes, I know it's not technically part of svn). Makes version-control accessible to pretty much anyone who can operate a mouse.
I'd love to move to git or mercurial or similar, but frankly Tortoise outweighs all that distributed goodness.

Re:#1 svn feature is, and has always been...

[ESqVIP]

Well, there's TortoiseHg. I haven't personally used it, but I guess at least the most common use cases are all covered.

Or is there something important missing on TortoiseHg?

How much time?

[Anonymous Coward]

Does anybody know how much time is going to pass, before 1.5.0 is released in debian?

Re:How much time?

[larry bagina]

Debian is run by volounteers in their spare time. They have other commitments and it may take a couple days before they have time to fuck up the source code with new vulnerabilities.

Bazaar looks good.

[Futurepower(R)]

Wow! I just looked at Bazaar.

Things I noticed:

Bazaar developers are very good writers. They explain things very well.

A lot of things they say make good sense to me. (Bazaar versus Git)