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
