How to Make a DVCS Completely Interoperable with Subversion?_问答_开发者

What architectural changes would a DVCS need to be completely interoperable with Subversion?

Many DVCSs have some kind of bidirectional interface with Subversion, but there are limitations and caveats. For instance, git-svn can create a repository that mirrors Subversion, and changes to that repo can be sent back to Subversion via 'dcommit'. But the git-svn manpage explicitly cautions against making clones of that repository, so essentially, it's a Subversion working copy that you can use git commands on. Bazaar has a bidirectional Subversion capability too, but its documentation notes that Subversion properties aren't supported at all.

Here's the end that I'm pursuing. I want a Subversion repository and a DVCS repository that, in the steady state, have identical content. When something is changed on one, it's automatically mirrored to the other. Subversion users interact with the Subversion repository normally. DVCS users clone the DVCS repository, pull changes from it, and push changes back to it. Most importantly, they don't need to know that this special DVCS repository is associated with a Subversion repository.

It would probably be nifty if any clone of the special repository is itself a special repository and could commit directly to Subversion, but it might be sufficient if only the special repository directly interacts with Subversion.

I think that's what mostly needed is to improve the bidirectional capability so that changes to Subversion properties are translated to changes in the DVCS repository. Some changes in the DVCS repository would be translated to changes to Subversion properties.

Or is the answer to create a new capability in Subversion that interacts wi开发者_开发百科th a DVCS repository, using the DVCS repository as just a special storage layer such as fsfs or bdb?

If there's not a direct mapping between the things that Subversion and a DVCS regard as having versions, does that imply that there's always going to be some activity that cannot be recorded properly on one or the other?

My conclusion after thinking about the answers I got plus some conversations with others is that there would necessarily need to be a one-to-one mapping between the things that Subversion and the DVCS can manage. If there's not, the true interoperability cannot exist.

I don't think there are any existing DVCSes that are even candidates for this. As Chris Kaminski points out, perhaps Subversion will be tackling the problem in the future by including distributed capabilities.

I asked the question because I work in an organization where we're nearing the end of a long, painful migration from CVS to Subversion. Subversion meets the organization's needs very well - to wit, having a centralized source of truth. There's a tiny but growing groundswell of sentiment among individual programmers that they want to use git or other trendy DVCS systems. Because git-svn is basically just a fancy Subversion client, there's a somewhat-happy medium. OTOH, having the centralized repository can cause annoyance, e.g. someone working in India with hundreds of milliseconds of latency to the server. Furthermore, it's only a matter of time before all of our new hires show up not having ever used anything other than git/hg/bzr/whatever. I think they're going to chafe at living in the world of the centralized Subversion repository.

So, I have been wondering whether there was a way to have it both ways: the Subversion repository that the organization wants and around which many other processes are built AND the shiny new DVCS tools that hipster programmers demand!

Sadly, I now think that's just not really possible. I think we're fighting the tide - I believe that the underlying concepts of Subversion are obsolete. Someday, we're just going to have to bite the bullet and fit DVCS technology into our infrastructure, then let individual projects decide whether they want to live in a Subversion world or a DVCS world.

It's called git, and using git-svn you can interoperate with Subversion clients. The caveat on git-svn isn't git <-> svn, it's (git <-> git) <-> svn. Basically they're saying that if you're using git to access an SVN repository, DON'T share your git repository with anyone else via push/pull. Otherwise it works just fine. You mostly get disconnected source code control of a networked subversion repository. That's all.

If you want something a little more "pure", there's SVK which is a DVCS built on top of Subversion, but it's been discontinued by the authors (though it is open source - PERL).

The subversion folks have some DVCS capabilities on the roadmap, probably spurred by the success of SVK and the growing prevalence of git/mercurial/bazaar.

I don't think there is truly a native way to make both tools fully inter operable, especially when you consider that:

SVN is a revision control which emulates tags and branches with directories
SVN doesn't record merge information the way Git does

(see SVN vs. Git)

So wanting that "DVCS-side users don't need to know that a Subversion repository even exists." is a bit far fetched, at least without an intermediate git like Chris suggests in his answer.

I would simply add to evaluate svn2git and git2svn in order to have your "DVCS-side users" dealing with a git repo not reflecting "directories" which actually should have been branches.
(see "Cloning a Non-Standard Svn Repository with Git-Svn")