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://username@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.
Received on 2012-12-31 15:06:41 CET