Hi Stefan,
Thank you for the quick response.
> 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
Admittedly, I've only briefly perused these two documents, but I did not
see anything that would _prevent_ distributed operation from being
implemented. Is there a particular feature of FSFS (or some other
module) that you had in mind here?
> 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
Yes, I did come across the vendor branching document earlier, but found
the solution emotionally unsatisfying. The fact that I must always keep
track of which revisions I already merged and then remember to use them
as baselines in merges is incredibly cumbersome, esp. if I previously
cherry-picked changes from the parent (in my case, LLVM) repository.
This is true for vendor branches as well as for your foreign repository
merge scheme.
> You could also ask for commit access to a branch in the llvm
> repository.
LLVM is a red herring here. The idea is to be able to branch off _any_
SVN-hosted project on another server and easily track/merge changes made
therein while simultanously making local modifications. And all this
without need for write privileges on the parent server.
I consider asking for commit access a mere workaround, and a terrible
one at that, for reasons of scalability and security. Should every
developer wishing to fool around with LLVM (or any other) sources
automatically be entitled to a branch on the central server?
A somewhat better workaround, which I currently use, is to check out
LLVM sources via SVN and then check them it locally via CVS. :-)
> BTW, it would have been better to send your question to the users@
> list.
> The dev@ list is off-topic for questions like this.
No, because I have already determined that SVN is presently unable to do
what I want it to do. :-)
> Anything more involved than the foreign-repos merge crutch above would
> be far from trivial.
I absolutely agree. For one, creating a cross-repository branch would
not be "cheap" like in-repository branching is, and so an "svn copy"
would in this case also have to perform something akin to "svn import".
Also, as you pointed out, revision # sequences in the two repositories
would not match and so that would need to be accounted for.
Alas, I did not ask if the task would be easy, but merely whether it
would be possible. :-)
> 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.
I'm sorry, but this is just dogma. The fact that SVN is presently
centralized in no way implies that it needs to remain that way forever.
And, while git and Mercurial might be good systems, the fact is that
LLVM, and many other projects, are stored in SVN and that is what I'd
like to branch off of.
> You should
> be engaging with the llvm community and get commit access, rather than
> maintaining an isolated fork.
Not only do I not have anything to "engage" the community with at the
moment, but in fact may never do so. SVN may presently be centralized,
but software development is anything but.
Happy New Year to all; I'm curious what others think of my idea also.
:-)
--Zem
Received on 2013-01-01 00:02:28 CET