On 25.08.2012 11:33, Stefan Sperling wrote: > On Sat, Aug 25, 2012 at 11:14:57AM +0200, Branko Čibej wrote: >> After all the discussions about this topic, I've slowly come to the >> conclusion that this is the best option. The only trouble I see is in >> properly supporting older WC formats, because as far as I can see, >> there's not much infrastructure in place for that. >> >> Unless you think that it's OK for newer SVN releases to simply not work >> on old working copies? > I thought the plan going forward was to require a working copy > upgrade when the user upgrades to 1.8. What I'm proposing is > that this upgrade should be a manual step as it was during the > 1.6 -> 1.7 transition, with the option of always auto-upgrading > for advanced users who know what they're doing. I've seen too > many inexperienced users run into problems because of auto-upgrade > during the 1.5 -> 1.6 transition (mainly users of multi-client > setups in large corporations). By comparison the 1.6 -> 1.7 > transition was a lot easier for those users because they were > made aware of what was happening. > > I'm not proposing to add read/write support of the 1.7 format to 1.8, > if that's what you're asking for. I know SVNKit has this feature > but it's a bigger task than I can add on my todo pile right now.
Makes sense. Except that I'd argue against having an auto-upgrade option. It seems to me that it would just complicate bug reporting without actually gaining anyone anything. If you're thinking about large-scale client deployments in contolled environments, surely the upgrade can be scripted as part of that. -- Brane -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
