I've filed issue #2961 to track this task against the 1.5 milestone.
http://subversion.tigris.org/issues/show_bug.cgi?id=2961
On Fri, 05 Oct 2007, Mark Phippard wrote:
...
> 1) The 1.5 client will automatically update the WC following whatever
> technique we did in 1.4.
>
> 2) We will create some kind of utility to downgrade a WC back to 1.4.
> This utility could have some checks warnings if dataloss would occur.
> For example, I think if the WC has "shallow directories" it probably
> ought to not downgrade it at all. If it has changelists it should
> probably issue a warning and tell you to re-run with a --force option
> or something.
I've implemented all of this in a new Python script,
tools/client-side/change-svn-wc-format.py, which I've committed to
trunk in r27055. It does NOT use our Python bindings to libsvn_wc,
and instead mucks with the WC meta data directly, to reduce
dependencies.
> 3) There is an obvious desire to do this with the bindings. Given
> that Windows users are our main target I'd greatly prefer a native
> solution. I do not care if it is a separate .exe or an option on a
> subcommand, but it would be better if this was in the libraries. This
> would also make it easier for TortoiseSVN to have an option to
> downgrade you and if we punched it through to JavaHL, then Subclipse
> could do it as well. Of course there are lots of other tools that use
> the libraries.
>
> If you can make a .exe that hides the fact that it is Python and the
> bindings then I can live with that. It cannot be really complicated
> to install though and the libraries would be better.
On Windows, we will native-compile this Python script into an .exe.
> This solution was briefly discussed when we went from 1.3 to 1.4 but
> the WC formats were do drastically different it would have been a lot
> harder to do. I think this is a fair compromise.
The script contains enough framework that implementing this would be
quite a bit easier.
> BTW, here is the use case I care about ... I think this is common.
>
> User is stuck using an older IDE with an older SVN integration. For
> example, there are a lot of Eclipse 3.0-based tools out there from IBM
> and other vendors. Users get stuck on these tools because of the
> proprietary tie-ins to their application and/or database servers.
> This user is using Subclipse 1.0.x which includes SVN 1.4 libraries.
>
> User also uses TortoiseSVN and happily upgrades when he sees 1.5 release is out.
>
> User plays around with TortoiseSVN features in their working copy.
> Unbeknownst to them, they do something that bumps the format of the
> WC.
>
> Users goes back to Eclipse to do something, and suddenly they get
> weird behavior and error messages.
>
> This happened all the time with 1.3 to 1.4 upgrade and users were
> forced to choose a tool and likely had to checkout projects all over
> again. Some of these users probably lost work because they did not
> think to use TortoiseSVN to commit changes before they did this.
>
> With a tool like the one proposed they could put their WC back to 1.4
> format and then just be more careful with how they use TortoiseSVN.
>
> By the way, most of us are aware of how painful the 1.3 to 1.4 format
> bump was on our user base. 1.4 was released in September 2006. Take
> a look at this chart of the adoption of Subversion since 1.4 was
> released:
>
> http://subversion.tigris.org/svn-dav-securityspace-survey.html
>
> That is an explosion in usage in the last 12 months. This means that
> this bump is going to be that much worse than it was last time. We
> need to do every extra thing we can to help users deal with this.
- application/pgp-signature attachment: stored
Received on Tue Oct 9 23:07:35 2007