incomplete directory props

[Ben Collins-Sussman <su...@collab.net>]

sussman@tigris.org writes:

> Continue work on issue #730:  restartable checkouts.
> 
> Still need to deal with making sure all dirprops are fetched for
> incomplete directories, that's coming up.

Actually, I'm not so sure we need to deal with this.

If the directory is incomplete, the client tells the server, and the
server assumes the directory has no entries and no props.  The client
re-adds the entries it has, but not the props.  This means the server
will automatically send *all* dir props back to the client.

Meanwhile, if you look at the way update_editor.c is set up -- notice
that all directory props are cached in memory until close_directory()
is called.  So that means all the dirprops are either on disk, or
they're not; there's no in-between state.   Then later on, long after
the dirprops are written to disk, the directory is marked valid.

So it doesn't matter where the editor gets interrupted.  When 'svn up'
resumes the process, it will automatically receive all dirprops.  If
there are no props on disk yet, that's fine; they'll be written out.
If there *are* a complete set of props on disk already, that's fine
too, they'll just be overwritten by another complete set.

So there's nothing to do here, right?

Hmmm, I guess this large glass of caffeine is working.  I just can't
seem to stop mailing the dev list tonight.  :-)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: incomplete directory props

[Jack Repenning <jr...@collab.net>]

> So it doesn't matter where the editor gets interrupted.  When 'svn up'
> resumes the process, it will automatically receive all dirprops.  If
> there are no props on disk yet, that's fine; they'll be written out.
> If there *are* a complete set of props on disk already, that's fine
> too, they'll just be overwritten by another complete set.

I think your logic does not depend on the fact that dirprops are
presently written all-or-nothing.  Even if they're half-and-half, the
dir is still marked incomplete and the server sends all props.

Even should the client and server start enumerating props to
individually update, the "incomplete" flag on the directory would be
enough signal: you'd just need a "low-confidence" mode for the props, as
you now have for the files.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: incomplete directory props

[Sander Striker <st...@apache.org>]

> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: Thursday, May 15, 2003 5:14 AM

> sussman@tigris.org writes:
> 
>> Continue work on issue #730:  restartable checkouts.
>> 
>> Still need to deal with making sure all dirprops are fetched for
>> incomplete directories, that's coming up.
> 
> Actually, I'm not so sure we need to deal with this.

If you add a 'right now' to that, then +1.
 
> If the directory is incomplete, the client tells the server, and the
> server assumes the directory has no entries and no props.  The client
> re-adds the entries it has, but not the props.  This means the server
> will automatically send *all* dir props back to the client.
> 
> Meanwhile, if you look at the way update_editor.c is set up -- notice
> that all directory props are cached in memory until close_directory()
> is called.  So that means all the dirprops are either on disk, or
> they're not; there's no in-between state.   Then later on, long after
> the dirprops are written to disk, the directory is marked valid.

It depends on if we ever decide to not keep all the dirprops in mem
before writing to disk.  If people start attaching huge property values
to dirs that might be problematic.  I personally don't see the practical
use for huge properties, but then there's users... ;)


Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org