On Thu, Sep 20, 2012 at 12:44 PM, Ben Reser <b...@reser.org> wrote: > On Thu, Sep 20, 2012 at 4:35 AM, Andreas Krey <a.k...@gmx.de> wrote: >> On Thu, 20 Sep 2012 06:36:02 +0000, Nico Kadel-Garcia wrote: >>> here! By keeping the software an integrated codebase for clients and >>> servers, they're able to make protocol changes that you'll be forced >>> to keep up with in an entirely distinct codebase. How can you *test* >>> that robustly? >> >> That is just shifting the problem. Either you have an API that you can't >> just modify, or you consider the wire protocol your API, and either way >> you have to be backwards-compatible and need something to test on that >> level. (Besides in my opinion the wire protocol is only that complex >> because you don't replicate - moving whole commits is easier than doing >> all the commands remotely.) > > It's worth pointing out that this problem isn't that big of a problem > for them. If they implement one version of our wireline protocol then > they are going to interoperate with us until we bump the major. Yes > they may be missing some features until they catch up, but they will > interoperate.
Except that it can't be merely wire protocol. They're remapping the commit, copy, delete, move,branch, tag, and merge operations of one source control into the other. That's..... not directly comparable, especially the tag operation, which is really designed to be much more locked down than Subversion has by default. In theory, I suppose you could lock it down to emulate the git "thou shalt not touch me" model. And unfortunately, there are Subversion usage models that simply don't map well to the standard trunk/branches/tags layout, such as matching simultaneous tags for source code and/or binaries of multiple parallel projects in the same repository.
