[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Help! Subversion Exception!

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 20 Oct 2011 21:17:46 +0200

On Thu, Oct 20, 2011 at 02:03:58PM -0500, Les Mikesell wrote:
> On Thu, Oct 20, 2011 at 1:58 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>
> >> > The unlucky user should simply get a new working copy.
> >> > Working copies are and have always been considered disposable.
> >>
> >> So why bother to upgrade them at all if success is unimportant?
> >
> > You misunderstood what I meant.
>
> No, I'm just being difficult because you didn't seem to care about the
> potential for losing uncommitted changes.

There are tools to merge local changes over from a corrupt working copy
to a new working copy. Some have been mentioned recently in the various
"help! expection" threads. I'd use rsync.

> > Most reports about failed upgrades so far were due to *corrupt* 1.6
> > working copies. We cannot safely upgrade them, see Philip's reply.
> >
> > We do care about upgrading good 1.6 working copies, and have
> > fixed several bugs in 1.7.1 based on the reports we received.
>
> Is there any tool that you can run to do a corruption check on a 1.6
> working copy that does not overwrite a needed 1.6 program and does not
> actually do the upgrade?

Not that I know of, unfortunately.
How to detect corruption also depends on the kind of corruption at hand.

> It seems like it would be a good thing to
> know whether or not you were ready to upgrade.

If in doubt, commit local changes before upgrading to 1.7.
If your admin took 1.6 away from you prematurely, complain to him.

I don't think this is a big problem because there are ways to cope.
And the benefits from updating from 1.6 to 1.7 are worth the trouble
in any case.

However, bugs that prevent good working copies from upgrading are bad
and need to be fixed.

Does this make sense?
Received on 2011-10-20 21:18:27 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.