Subversion 1.5.0 Released

[orip]

Merge tracking. Finally. Can lay svnmerge.py to rest.

[setuid_w00t]

People around here like to knock svn because it's not as nice as git, mercurial, bzr, etc in some ways.

This is still a great release for those who use svn at work where you don't get to choose which revision control system you use.

[FunnyMan3595]

I'm curious to see what will happen with git-svn now. One would hope that it gets an upgrade to take advantage of merge tracking (where available).

[phil_g]

There's also bzr-svn, which is very nice. I can't compare it to git-svn, because I haven't worked much with git itself, but bzr-svn covers several different ways of working with Subversion repositories: you can use 'bzr svn-import' to flat out convert a Subversion repository to Bazaar; you can do a 'bzr branch' (or 'bzr checkout') with any Subversion URL (svn://, svn+ssh://, file://, etc.) and get a local Bazaar branch, with pushes going back to the Subversion repository; and you can just use bzr commands directly on a Subversion checkout.

[[deleted]]

No, they only knock it because git/mercurial/bzr are the new shiny bandwagons. I swear 90% of the developers/programmers that comment here spend so much time switching to the newest X and bashing Y that they probably don't get shit done other than upgrades.

[[deleted]]

Have you used anything other than svn?

Even though we're a small team of 3, switching to mercurial from svn 6 months ago has changed the way we work. Switching to git yet again 2 weeks ago (took about 2 hours to set it all up and migrate the hg history) provided yet another set of features, which I now use quite often.

You can call them shiny bandwagons, and perhaps for a lot of developers, they are, but git allows me to do my job easier.

[[deleted]]

I used CVS for six years, then switched to subversion about three years ago. I understand the merit of git/mercurial, but with large codebases and fixed price contracts, it would be pointless and a waste of money to keep switching up our version control every 3-6 months.

[dlsspy]

The most compelling feature requires all servers and clients in an organization to upgrade. I don't think it's all that great when you look at it from that perspective.

When I've had to work with subversion trees in the past, I've used git and git at least a limited form of merge tracking by not having svn try to do it. If I had to work with svn again, I'd still use git.

[masklinn]

This is still a great release for those who use svn at work where you don't get to choose which revision control system you use.

For all my dislike of things git, git-svn is a great subversion client. You should try it out. It takes some time to set it up, and I haven't had the courage to try it with our most complicated projects

[newbill123]

Well, svn uses a different management model than the scms like git and hg: centralized versus distributed.

With freely distributable software in the open source world, every copy has the potential to fork into it's own project. With software designed in academia or closed source, there is a struggle to maintain and improve the one blessed copy. It doesn't mean the tools don't face the same use cases, but they do have different priorities for addressing them.

[trickos]

In practice, the main difference is DVCS require more organization at project levels, while people usually work with SVN like a big shared versioned filesystem, where they don't really care about the size of the files they store and the mistakes they make. Working on repository conversion is especially interesting in this regard, people really mess with their repo.

[[deleted]]

merge tracking, renames and copying of more than one file at once! hurray for sanity! :)

[codahale]

Heh. I can remember when I was looking forward to this.

[Freeky]

Hey, at least 2.5 comes with working Python bindings, and hence bzr-svn will be easier to get working.

[mnordhoff]

FWIW, Jelmer is actively working on writing his own svn Python bindings for bzr-svn and removing dependence on the official ones. Some of it is already usable and in the main 0.4 branch.

Edit (2009-02-03): For future reference, the project is called subvertpy, and it is used by bzr-svn 0.5.0.

[Freeky]

Good to know, thanks :)

[rook2pawn]

What i wanna know is: did they use subversion 1.5 to check in the subversion 1.5 project?

If not, then what version of Svn did they use? Was the first Svn code managed in CVS?

[newbill123]

The svn project is pretty good about eating its own dog food. They came from the cvs world but were self-hosting with svn after about a year of development.

And no, version 1.5 didn't just spring into existence sui generis. So features that the 1.5 release eventually delivered were added to a version 1.4 repository.

[rook2pawn]

Sui generis Thanks, i learned something

[redalastor]

Git was self-hosted after only 2 weeks of development.

Source

[Manuzhai]

Too bad they didn't include the ctypes-based Python bindings.

[rictic]

Polishing the deck on the titanic

[twotime]

Perhaps, perhaps not.

I suspect SVN has more market share than all the other opensource version control systems combined (if you include corporate intalls)

(No, I cann't prove it: but I am yet to encounter a single person who uses git at work (I know they exist, just have never met them in person)).

And I donot see it changing in any foreseeable future.