On Wed, Jul 11, 2012 at 5:29 PM, Mark Phippard <markp...@gmail.com> wrote: > On Wed, Jul 11, 2012 at 8:21 AM, Johan Corveleyn <jcor...@gmail.com> wrote: >> >> On Wed, Jul 11, 2012 at 4:23 PM, C. Michael Pilato <cmpil...@collab.net> >> wrote: >> ... >> > That said, I'm not really in favor of us maintaining multiple codepaths >> > (based on WC version) in the client. I just don't see the cost >> > justifying >> > the benefit. I mean, it makes sense to do so in the repositories as we >> > do >> > today, because the cost of any Subversion upgrade could be equivalent to >> > the >> > cost of a full dump/load of the repository. I think that's too much to >> > ask >> > of our administrators. But for working copies? >> >> >> On Wed, Jul 11, 2012 at 4:27 PM, Mark Phippard <markp...@gmail.com> wrote: >> ... >> > We have always had a problem delivering new features as fast as our >> > users >> > want to see them, I would hate to see us adopt new policies that just >> > make >> > it harder for us to turn the crank on new releases and new features. I >> > would be against trying to support multiple formats for this reason. >> >> Hmz. The fact that we don't deliver features as fast as our users want >> is mainly a resources vs. effort issue. But this doesn't seem that >> much different from any other "feature" to me (of course there is a >> cost in developing the framework/infrastructure/... to support older >> working copy formats). But maybe you're talking about a recurring >> increase in effort for every release from now on. >> > I think the effort would be enormous. As one example, we would need to > figure out how to make our test suite test it and then ideally we would all > run those tests with each change. Any time someone makes a change involving > the WC they need to factor this in. I think it creates a fairly significant > burden on almost every change that we make.
Concerning test effort, I think we can be pragmatic, and just not test this systematically. Similar to how we currently support 1.7-server with 1.x format repositories. I mean, does anyone systematically test our 1.7.x release candidates with a 1.6 or 1.5 repository? The same with our client-server compatibility: do we systematically test 1.7 clients with 1.6 or 1.0 servers? No, we might test those if someone reports a specific issue, but other than that it's best effort ... Concerning developers having to take this into account all the time: yes that's true. They/we need to be aware of it and be careful not to break the N-1-compat code. But how hard that is will depend on how we implement this "feature". For instance, we could simply package two set of binaries/libraries in one package (the 1.8.0 version together with 1.7.x (taken from the corresponding tag)), and implement a main wrapper that delegates everything to the appropriate version. The 1.8.0 code doesn't need to care about the 1.7-compat stuff, we just have a dispatcher and package the old code together with it. I'm just fantasizing of course, for illustrative purposes only :-). But ... it depends. Anyone have a creative idea how this could technically be done and what the pros and cons would be? -- Johan
