On Wed, Jul 11, 2012 at 8:21 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Wed, Jul 11, 2012 at 4:23 PM, C. Michael Pilato <cmpilato_at_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 <markphip_at_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.
I guess I could be wrong, but that is how it seems to me.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-07-11 17:30:00 CEST