On 10/5/07, Daniel L. Rall <dlr@finemaltcoding.com> wrote:
> On Thu, 04 Oct 2007, David Glasser wrote:
> > > Maybe I am wrong, but I thought with 1.4, even something like status
> > > updated the WC.
> >
> > Nope; just tested.
>
> Hmm, then why all the noise about third-party clients, especially those
> integrated into GUI shells (e.g. TortoiseSVN and SCPlugin), automatically
> upgrading your WC while browsing your local file system?
My guess is my memory exaggerated the problem. I remember managing
the problem for a while when I still needed to use an old Subclipse
version that was using 1.3. I just stayed away from those WC's with
TortoiseSVN and I was OK. I suspect you need to do something like
update that really touches the WC.
We were discussing this ... yet again ... on IRC and I backed down a
bit and offered a compromise. Here it is...please comment.
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.
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.
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.
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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 6 01:47:51 2007