On Mon, Dec 31, 2012 at 03:36:16AM -0800, Ziemowit Laski wrote: > Hello, > > > > I'm playing around with LLVM sources and would like to make local tweaks > while keeping track with ongoing development in the trunk. I tried > issuing the command: > > > > svn copy http://llvm.org/svn/llvm-project/llvm/trunk > svn+ssh://usern...@myserver.net/usr/data/llvm-local > > > > to which SVN responds: > > > > svn: E200007: Source and destination URLs appear not to point to the > same repository. > > > > My question is this: Is there a compelling technical reason why > branching must occur within the same repository?
Subversion hasn't been designed for distributed operation. See https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/notes/fs-history and https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure As a workaround you could use vendor branching, see http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html The book suggests to use svn_load_dirs.pl to pull upstream changes. I'd suggest using foreign-repository merges instead. Revision numbers in their and your repositories won't match up, but it's a nice way of preparing patch submissions. The basic idea is to merge the entire llvm trunk into a repository of your own. Note that copies are translated to plain additions, since copyfrom info from the remote repository isn't valid in the local one. The relevant bit from 'svn help merge' is: - Merging from foreign repositories - Subversion does support merging from foreign repositories. While all merge source URLs must point to the same repository, the merge target working copy may come from a different repository than the source. However, there are some caveats. Most notably, copies made in the merge source will be transformed into plain additions in the merge target. Also, merge-tracking is not supported for merges from foreign repositories. Look up the current head revision of the llvm repostiory. You need to remember that number for the next future merge. I'll call this HEAD below but you should not use 'HEAD' literally since HEAD is a moving target. (Make sure you're using Subversion 1.7 for this, not earlier releases!) svnadmin create repos svn mkdir file://`pwd`/repos/llvm svn co file://`pwd`/repos/llvm wc cd wc svn merge http://llvm.org/svn/llvm-project/llvm/trunk@r1 \ http://llvm.org/svn/llvm-project/llvm/trunk@HEAD svn commit Because llvm deleted its own trunk in r70891 and restored it as a copy of itself in r70892, Subversion will break down the merge into two ranges and merge them in succession. When the second range is merged this results in some additions on top of existing local additions (from the first merged range), so Subversion will flag some tree conflicts. The conflicts can be avoided like this: svn merge http://llvm.org/svn/llvm-project/llvm/trunk@r1 \ http://llvm.org/svn/llvm-project/llvm/trunk@r70890 svn commit svn merge http://llvm.org/svn/llvm-project/llvm/trunk@r70892 \ http://llvm.org/svn/llvm-project/llvm/trunk@HEAD svn commit Now start committing your own changes, possibly on a separate branch off ^/llvm within your local repository. You can create a branch from within the 'wc' working copy like this: svn copy ^/llvm ^/mychanges The ^/ means "URL to repository root". Each time you want to merge new upstream llvm changes, look up the current head revision again (NEW_HEAD) and run: svn co file://`pwd`/repos/llvm llvm-wc cd llvm-wc svn merge http://llvm.org/svn/llvm-project/llvm/trunk@HEAD \ http://llvm.org/svn/llvm-project/llvm/trunk@NEW_HEAD svn commit Then merge upstream changes into your own branch: svn co file://`pwd`/repos/mychanges cd mychanges svn merge ^/llvm When you have changes to submit upstream, run something like: svn diff --show-copies-as-adds ^/llvm ^/mychanges You could also ask for commit access to a branch in the llvm repository. Whether or not such access is easy to obtain depends on rules set up by the llvm community. Subversion has been designed to make granting commit access easy and secure -- no server system accounts are needed, only a set of credentials to authenticate to httpd, and commit access can be restricted to a subset of the repository. But how this is handled in practice ultimately ends up being a question of community management, rather than a technical question. BTW, it would have been better to send your question to the users@ list. The dev@ list is off-topic for questions like this. I suppose you chose dev@ because of your idea to develop support for cross-repository copies, which I'll address now: > I'm tempted to try my > hand in adding cross-repository branching to SVN, but would like to make > sure first that this is not impossible. For example, I have read-only > access to the LLVM repository (like most mere mortals), so if branching > requires that some metadata be written there, then this would be a > no-go. Anything more involved than the foreign-repos merge crutch above would be far from trivial. And there is no point in making Subversion a distributed version control system. There are already good enough distributed systems out there (git and Mercurial being popular choices). Subversion is a about centralised version control. You should be engaging with the llvm community and get commit access, rather than maintaining an isolated fork.
