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?
