Regression in working copy logic?

[Justin Erenkrantz <ju...@erenkrantz.com>]

Doing an update with svn trunk (r5971) on one of my repositories yielded:

% svn up
svn: No such file or directory
svn: could not save file
svn: svn_io_file_open: can't open `.svn/tmp/text-base/myfile.svn-base'

(the myfile changed in the repository)

It's apparently because the .svn/tmp/text-base, .svn/tmp/prop-base, 
.svn/tmp/props, .svn/tmp/wcprops directories were missing from my working 
copy.  Explicitly mkdir'ing them fixes the problem and all is well.  (Deleting 
them in your working copy will reproduce this whenever a file is updated.)

But, I never touched this .svn directory, so I'm wondering if it's possible 
that at one point, the svn client didn't create them.  This working copy was 
created a long time ago.  However, fresh checkouts seem to create these 
directories.

Wouldn't it be nice to be a bit more graceful in this situation if indeed 
older clients never created these directories in .svn/tmp?  If so, I can come 
up with a patch that detects this scenario and creates the directories.  (In 
fact, I'll come up with it anyway right now.)  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Regression in working copy logic?

[kf...@collab.net]

Justin Erenkrantz <ju...@erenkrantz.com> writes:
> > I'm not sure whether we should be graceful or not.  I mean, in one
> > sense, the working copy adm area has been tampered with.  Who knows
> > what else might be wrong?  Recovery is a slippery slope...
> 
> Well, if older SVN clients never created the .svn/tmp/text-base
> directories, then it really hasn't been tampered with.

Wow.  How old are we talking about here?  Those directories have been
created for a long time, I think.

> FWIW, running 'svn cleanup' fixes this as it forces the creation of
> these directories in the .tmp area.  Perhaps we can wrap the svn error
> in this case with a description to 'please run svn cleanup on this
> working copy.' That seems fairly painless - you wouldn't know by
> looking at the error that this would be an acceptable solution, but it
> is.  -- justin

+1  (go for it)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Regression in working copy logic?

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On Monday, May 19, 2003 12:34:07 -0500 kfogel@collab.net wrote:

> I'm not sure whether we should be graceful or not.  I mean, in one
> sense, the working copy adm area has been tampered with.  Who knows
> what else might be wrong?  Recovery is a slippery slope...

Well, if older SVN clients never created the .svn/tmp/text-base 
directories, then it really hasn't been tampered with.

FWIW, running 'svn cleanup' fixes this as it forces the creation of these 
directories in the .tmp area.  Perhaps we can wrap the svn error in this 
case with a description to 'please run svn cleanup on this working copy.' 
That seems fairly painless - you wouldn't know by looking at the error that 
this would be an acceptable solution, but it is.  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Regression in working copy logic?

[kf...@collab.net]

Justin Erenkrantz <ju...@erenkrantz.com> writes:
> Wouldn't it be nice to be a bit more graceful in this situation if
> indeed older clients never created these directories in .svn/tmp?  If
> so, I can come up with a patch that detects this scenario and creates
> the directories.  (In fact, I'll come up with it anyway right now.)

Weird.

I'm not sure whether we should be graceful or not.  I mean, in one
sense, the working copy adm area has been tampered with.  Who knows
what else might be wrong?  Recovery is a slippery slope...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org