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

Re: export, checkout, commit performance

From: Ivan Zhakov <chemodax_at_gmail.com>
Date: 2006-03-13 16:15:33 CET

On 3/13/06, Peter N. Lundblad <peter@famlundblad.se> wrote:
> 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.
Hmm, interesting idea. I'll investigate how complex it will be. Also I
can use WC_FORMAT for detecting old working copies.

> 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.
I can't figure how txdelta can send delta without reading whole stream?

> 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?
Yeah, I had similiar idea recently. But in this case we need extra
allocations of read buffer. I don't know how it decrease performance.

>
> > 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.
Thanks for explanations.

>
> 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.
>

--
Ivan Zhakov
Received on Mon Mar 13 16:19:29 2006

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.