Re: [Gnu-arch-users] Idea for a feature

[Tom Lord]

    > From: James Blackwell <address@hidden>

    > > My first concern would be race conditions. All writers would need to
    > > update the same file. Secondly, if you have different security on
    > > different branches, you'd need to allow everyone with any write access
    > > to alter meta-data, which is IMO not desirable.

    > 
    > I think it would probably be ok. No matter what happens, we always end up
    > with the most recent date. if either finishes first, the latter one wins
    > and gives us the date/time we want. If they both finish at the same time 
(smp?),
    > we end up writing the same date/time twice and we still end up with what
    > we want. Way off in the distance, the only thing mirrors care about is
    > "Is that date there newer than my date here?"

Your idea solves an old puzzle.   Some time ago, we pondered adding
recursive .listing files to archives in order to speed up mirroring.
That turns out to be an unworkable idea.   Your timestamp idea is much
closer, though it needs some minor tweaks to actually work.

You are thinking, I think, about about timestamps in inodes of files.

Those aren't accessible (for files in archives) to arch.

It won't do to have clients write a timestamp in the contents of a
file -- that would require clock syncronization among all clients.

The best we could do is to have clients generate a probabilistically
unique id to serve as the contents of the file.   That would, however,
be sufficient for the task at hand.

This solution could be applied recursively leading to a fine-grained
optimization.  It guarantees that after changing the archive, and
precluding the event of premature client, server, or connection death
(which can be recovered from by archive-fixup), the relevent
"changestamp files" always changes contents -- which is enough for an
archive-mirror process to prune its probes of an archive accurately.


    > Your second objection is certainly more serious. Though I can imagine that
    > situation existing, I don't think it would be a common one. I would
    > imagine that in most cases, rather than working in an archive in which
    > permissions are restricted (except for a certain branch), people would
    > create their own archives.

Let's suppose that any directory in an archive (above the revision
directory level) can (optionally) have a ".change-id" file.   Let's
call archives that use this feature "change-stamped archives".

Normally, whenever a client adds a revision, it should update the
change-stamp of each parent directory of the revision directory, up to
the archive root.   In particular, it should store a newly generated
p.u.i.d. there.

An archive-mirror call taking a change-stamped archive as its source
would then be required to read the top-level change-stamp file.  If
that has changed, it must read the change-stamps for each category,
and so on recursively.

Now, let's make a special case:  if a change-stamp file for a given
directory contains just the string "not shared", then an archive
mirror process must recurse below that directly unconditionally, and
clients must not attempt to overwrite that file.   (That solve's Rob's
second concern.)

Very nice.

-t