Ivan Zhakov writes:
> >
> > Also I mention there is additional checksum checking in case if not
> > fulltext deltas sent, which also can be avoided if move it before
> > editor->close_file() call. This mean that checksum will be checked
> > after transmission, but before closing file. I consider this is
> > acceptable.
> >
> After detailed analysis I found that is impossible -- text_editor
> wants base checksum BEFORE receiving delta. But we can calc checksum
> during copy file to temp base.
The textbase is not copied to a temporary location (only the working
file that *will become* the text base). But, you can use the checksum
from the entries file and verify that on the fly when the text delta
is being transmitted. We need to be careful with compatibility with
WCs created before 2003-02-13, though, but you should be able to use
the length of the checksum string to detect if it is base64
encoded. Also, we need to make sure that the whole text base is
read. I'm not sure if the txdelta generator will do that if the
working file is considerably shorter than the text base. Maybe it is a
good idea to get rid of the read_all parameter of the
svn_stream_content_same function and instead create a new stream that
will "drain" its underlying stream when it is being closed. Thoughts?
> Step (5) odd for me. We check for modifications to make decision about
> right timestamp. But IMHO presence of temporary file already means
> text modifications, is it correct?
This checks if the working file was modified *after* the temporary
file was created. I.e., you start a commit of a large file, which gets
copied into a temporary file. Something modifies the working file and
after that, the commit is finalized. There obviously is a race here
(the file might be modified after you start checking for identity and
before the timestamp is set). I *think* the intent is to avoid
undetected modifications as far as possible.
An alternative might be to fetch the timestamp of the working file
when copying it in the svn_wc_transmit_text_deltas function and use
that timestamp in the entries file in the post-commit processing. I'm
not sure how that would interact with the read-only and executable
permission changes post-commit, though.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 13 15:37:26 2006