[LLVMdev] svnsync of llvm tree (original) (raw)

Oliver Schneider llvm at assarbad.net
Fri Feb 27 03:31:42 PST 2015

Hi,

On 2015-02-27 10:41, David Chisnall wrote:

I think it would be easier to understand why you want this if you had a use case for having an svnsync clone. Aside from backing up the repository, it seems like a fairly useless thing: you can't do local commits and then upstream them and you can't do well more or less for backup purposes, yes.

Local commits are not necessary, say, if I rarely commit. Because I could 'svn relocate' my working copy to point to the upstream repo before committing. And to reinforce that I really don't want to commit to my local "clone" I can install a hook script preventing me from doing that.

A very realistic use case is that people in a big organization could use the same local copy to checkout and the upstream repo to commit.

SVN over HTTP isn't exactly the most efficient protocol there is, so if I can skip thousands of revisions via SVN over HTTP and get going more quickly, that helps a lot.

If you want the complete history of the repository, then a git clone of the git-svn mirror will give you this very cheaply and with the added bonus that you can then commit to the local copy and still push things upstream (and merge changes from upstream). A fresh clone of the llvm and clang git mirrors transfers about 310MB for LLVM and about 190MB for Clang. And the desire for getting that in the SVN form is mainly coming from the imperfect representation of the history in the git-svn mirror (as you will also find from some recent and older threads).

Besides, the llvm-project SVN repo contains everything whereas the Git mirrors provide only slices of a handful as far as I know.

I know git-svn kind of works, but it's a crutch. But of course it provides the means for cooperation between SVN and Git users, so that aspect is good.

What do you want to do with the svnsync copy? Personally I wanted to keep an updated SVN copy and work on providing a better (continuously updated) Git and Mercurial representation of the repository (or repositories, need to look into that).

I have gathered experience with repository conversion (using reposurgeon) and thought I could apply it to something more complex, too. I also learned that there are quite a few "Subversionisms" that can cause problems in the conversion. Likely one of the reasons why the git-svn mirrors are not quite perfect.

This could be quite useful if and when LLVM decides to move to any other version control system that supports git-fast-import streams. For this, of course, one needs a true-to-the-bit copy of the repo and not something like the imperfect git-svn mirror :)

Also within our company I'd like to use it in the same way I described above (it's not the first repo I do this with, but it's one of the bigger ones). On the local network the transfer even of large amounts of data is a lot faster. I cannot say I ever enjoyed the speed of SVN much, but at least on the local net it becomes less of a nuisance.

Of course it's easy to put me on the spot about use cases when I only have one or two for myself, but there are probably more use cases out there due to some of the inherent weaknesses of SVN compared to distributed version control systems.

The mailing list thread back then proved there was demand for it. Creating a dump is a one-time effort. It can (but doesn't have to be) redone every few ten thousand revisions to provide additional chunks on top of the initial seed file or even create a fresh base seed file. And it saves traffic.

I cannot offer more reasons than that, sorry. Perhaps someone else can.

Oliver

More information about the llvm-dev mailing list