Subversion 1.5

SUbversion 1.5.0 has been released. I plan to upgrade when 1.5.1 is released. See the announcement for full 1.5 details. Things I like are:

  • Merge tracking
    There are still a few known issues with this. This is why I want to wait until 1.5.1.
  • Sparse checkouts
  • Relative URLs in svn:externals
    Allows stuff like /svn/someotherproject/trunk. Avoids the http vs svn+ssh.
  • Memory leak fixed
    There was a memory leak which caused problems for bzr-svn and others.

SVN dump+reload script?
I still have to dump/reload all GNOME repositories for the server to use the SVN 1.4 repos format. I’d appreciate if someone has a smart script for this to minimize any downtime (by doing the dump+reload in two stages, first stage dump+reload, 2nd stage disables permissions, dumps+reloads any commits done during the 1st stage, then moves over the 1.4 SVN in place, lastly enabling access again.. this per repository).

6 Replies to “Subversion 1.5”

  1. Why do you not consider git to be viable? I’m quite happily using git-svn over the current repositories with no problems, and John Carr has a full git-svn mirror now at
    I know bzr seems to be the flavour of the month with regards to DVCS but it still has the same problems that git does, in particular with being able to handle svn:externals.

  2. It is not a full git-svn mirror. Git-svn breaks on a few modules. Further, it took John weeks to setup that mirror.

    Bzr I can understand and admin, Git not.

  3. It was only missing two modules, which I’d successfully converted myself anyway. Also the issue with gtk+ is fixed in git HEAD. The only reason it took so long really was a lack of understanding of exactly how git works.
    Just because setting up a git-svn mirror initially was slightly tricky doesn’t make git less attractive since when the repos are converted fully, you are then admining a normal git repo which is more straightforward to do. All I’m asking is don’t rule it out yet!

  4. James: I don’t rule stuff out on their SVN integration, although if Gits SVN integration was better, maybe we could just use the mirrors for a while longer. Apart from other things, one problem I have is that I am a sysadmin. This means that I’ll have to support the infrastructure later.. doesn’t matter if I set it up initially or not. If I don’t understand it, then I cannot support it ( gets more than just ‘create a new repos pls’). Even if someone does the work of setting it up, I think the support will end up with me… I do not want that.

    Also still not having ‘grasped’ git is very annoying. I just don’t understand how it works (what happens at what stage).. I am not prepared to sit with a notebook or think of it as a filesystem or something (suggestions I got). Further, an ‘easy’ frontend doesn’t help when you get error messages. The tool itself has to be really easy (and it is not there at all).
    I know this depends on the person. Some pick it up (very) quickly.. but others take months+. Other stuff was way easier to pick up (remember learning Python.. even Perl.. etc). At one point I’ll understand it.. but I don’t see the benefit with how much time I have to invest (I want/need to work on sysadmin things like Mango TODO items).

    A VCS switch is more than just converting repositories. E.g. think of the scripts depending on/integrated with the VCS (auto updating of websites, auto building release-notes+gnome-devel-docs tarballs for libgo, etc).

    I am not the only one deciding… although if I’d support it, I will do the conversion (the whole thing, from investigation all implications to ensuring there are no issues).

Comments are closed.