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 with 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.