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

Re: SVN need to delete/create-temp/rename files instead of simply ove rwriting them (suggestion how to workaround)

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-12-05 19:52:15 CET

Ben Collins-Sussman <sussman@collab.net> writes:

> On Dec 5, 2004, at 5:33 AM, Teblin, Ivan wrote:
>> It must be a simple fix regarding only file-saving routine and I
>> hoped you
>> would concider it easy to develop. Anyway, if you think there're some
>> difficulties to implement it, I'll try to get my own hands to SVN
>> sources
>> and implement a patch to add the suggested "extra-compatibility"
>> option for
>> overwriting files instead of renaming/deleting them. Any suggestions
>> how to
>> name the option? "--fastsave"?
> I don't think we would accept such a patch.

I don't think it's even feasible to implement such a patch.

There are two files, the pristine text-base and the working file.
Update sends a diff (in vdelta format) and this gets combined with the
text-base to produce a new text-base. I don't think there is an easy
way to do this "in place" as applying the vdelta requires the original

Once the new, temporary, text-base is available a log file is written
containg commands to construct the new working file and to move the
text base into place. If the working file has local mods this
involves a three-way merge between the two text-bases and the working
copy, so both text-bases are required. If the working file is
unmodified it is a direct copy of the text-base only if svn:keywords
and svn:eol-style are unset, otherwise translation is required. All
these create a temporary working file, and the log file commands cause
both text-base and working file to get moved into place.

Your original problem was the loss of NTFS meta-data caused by the
moves. I suppose you could replace the final moves with copies into
the existing files, but you would lose the atomic guarantees that
Subversion currently gives. I suspect any such additional copy would
be slower than the current move so "--fastsave" is not appropriate :)

I encourage you to think about libsvn_wc improvements, but please
understand that it's complicated stuff.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 5 19:53:19 2004

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

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