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.
Maybe we can scope the feature a bit to reduce the (recurring) effort:
1) We only support format N-1, so only the immediately previous version.
2) We only support it in the same way as we currently support client
version N-1 (only security / data-corruption bugfixes ...).
We have to maintain version N-1 of the software anyway, so for a
little extra overhead we can maybe also support the
client(N)-workingcopy(N-1) variant.
I think this would be a great benefit to our users, especially in
enterprise environments. It avoids the "big bang" moment for users
(like me and a lot of my colleagues) where you currently have to
coordinate the upgrade of your 3 clients and 100 working copies into
one single moment in time, to make sure you can keep on working.
I just had a chat about this with a colleague, and he also commented:
"the least they can do is support the previous working copy format
(only that one), so my environment doesn't break immediately after
upgrading one client".
Is there really no creative way to do this? We support all our old
public API's (deprecated) into eternity...
Right now, I'm into the habit of keeping around my previous svn
(commandline) client installed on my machine, and I rename svn.exe to
svn-1.6.exe (and keep it in my PATH). Whenever I have to do something
with an older working copy, I just call svn-1.6.exe and do my thing
(after first running svn.exe, and encountering the "please upgrade"
error of course :-)). Why can't the client do that dispatching for me?
--
Johan
Received on 2012-07-11 17:22:37 CEST