Ben Collins-Sussman <firstname.lastname@example.org> 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
>> 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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Dec 5 19:53:19 2004