Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> On Mon, Nov 25, 2002 at 11:57:09PM +0000, Philip Martin wrote:
> > That's not correct, entries are cached for all operations. At present
> > operations that modify the working copy will repeatedly *write* the
> > entries file, but it does not get read repeatedly. Writing happens
> > repeatedly because a) that's how it worked originally, and b) if it
> > didn't then an interrupted operation would lose all its modifications.
> > (I know interrupted checkouts cannot be restarted, but that's a bug
> > that needs to be fixed.)
>
> I took a quick look at this, and the update editor for checkouts is created
> with a null adm_access.
Tricky to do otherwise for a checkout...
> Maybe it is created and used later, but I didn't see
> it.
The update editor caches the access batons within the editor. At
present there is no simple way to return those to the caller (see
close_edit), so if the caller wants to do something else, such as
storing auth info, it needs to open them again.
I have remembered that entries files may be read twice for some
operations. There are two sets of entries, one without deleted items
(not items scheduled for deletion, but items in state deleted) and one
without. The caching code creates which ever set the read code asks
for, but if the one with deleted items is available it uses that to
create the one without, and thus avoids parsing the file. So if an
operation requires both sets, but asks for the set without deleted
items first, then the file will get parsed twice. It's a memory/speed
tradeoff. If we always created the entries set with deleted items
even if the read code asks for the set without, we would not sometimes
parse the file twice, but we would sometimes use more memory.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 26 01:32:04 2002