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

Re: [test fail] merge_tests.py 12 / r39114

From: Hyrum K. Wright <hyrum_at_hyrumwright.org>
Date: Fri, 4 Sep 2009 10:02:00 -0500

On Sep 3, 2009, at 5:49 PM, Stefan Sperling wrote:

> On Fri, Sep 04, 2009 at 12:35:31AM +0200, Neels Janosch Hofmeyr wrote:
>> svn: Can't move '/tmp/tempfile.3.tmp' to
>> 'svn-test-work/working_copies/merge_tests-12.other/A/theta': Invalid
>> cross-device link
>
>> <hwright> but with centralized metadata, we won't be able to
>> guarantee
>> same-device temp areas anyway
>> ...
>> <hwright> I don't know what we're using the temp area for in that
>> context,
>> but I'd assume we have a way of getting around such things?
>
> In svn patch, we create a temporary file which will be renamed
> on top of a target file in the exact same directory as the target
> file itself to avoid cross-device renaming issues.

What happens if the operation fails somewhere in the middle? How does
the temp file get cleaned up?

The larger problem here is that in a number of places we assume the
atomicity of moving a file within a device. While the .svn directory
could theoretically be on a different device than the rest of its
parent, practically that isn't the case. We've just always assumed
that putting something in foo/.svn/tmp and then moving to foo was
atomic.

With the consolidation of metadata, and the possibility of metadata
living somewhere completely disjoint from the actual working copy, we
lose the ability to do these atomic moves. There are also other
issues which might come into play, such as the cross-device linking
problem described above. I haven't yet thought through them all, but
I have thought enough to know that the current paradigm may need to
change.

-Hyrum

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2391034
Received on 2009-09-04 17:02:20 CEST

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