Hi,
Wouldn't it be great if svn could keep around code for handling older
working copy formats, and for upgrading/downgrading working copies at
will between a certain number of formats? Or like danielsh recently
suggested during a discussion on users@ [1]: don't make format
upgrades mandatory (like we do for FSFS formats), but keep the ability
to read from and write to older formats?
This has always been a bit of a weak point of client-side svn IMHO,
the fact that the client isn't compatible with older wc-formats. Now I
understand that for 1.7 this wasn't really realistic with such a big
rewrite, and things just really had to get cleaned up. But maybe in
the future, better backwards compatibility would be feasible?
Also, it seems that SVNKit (with its pure-Java reimplementation of
svn) provides such backwards compatibility: the latest release (1.7.4)
supports all formats from 1.3 onwards, and can upgrade and downgrade
between formats (except that it cannot downgrade from 1.7). This is a
big convenience for my developer colleagues: they can simply upgrade
their IDE (IntelliJ IDEA in this case) with its svn plugin, and they
can still keep working with their old 1.6 working copies. They can
upgrade them at any convenient time, one by one. If half of them are
on 1.6, and half on 1.7 ... no big deal, they can just keep working.
Also, during 1.6 -> 1.7 migration, svnkit is very handy to have around
in case there are upgrade problems. If upgrade fails for reasons of
1.6 requiring cleanup, you can just use the same client to run the
'svn cleanup' on the 1.6 wc (svnkit has a commandline wrapper with the
same CLI interface as standard svn).
It's a pity that SVNKit was so late with their release, but this
ability is a big convenience IMHO, and a major differentiator of
SVNKit over standard svn. I just wish svn could do the same ...
--
Johan
[1] http://svn.haxx.se/users/archive-2012-04/0228.shtml (script to
detect timestamp-mismatches (inefficiency) in (1.7) working copies?):
the idea of 'svn status' automatically fixing broken timestamps came
up, and difficulties of doing this were discussed, a.o.
(auto-)upgrade.
Received on 2012-04-22 21:21:38 CEST