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.
