Re: [Gnu-arch-users] Re: [BUG] feature plan -- Selected inventory

[Jason McCarty]

Aaron Bentley wrote:
> If there's a new file in the selected area with an existing ID
               ^^^^^^^^
This condition can be detected easily. Apply the selection to the
project tree and the pristine tree, and compare the two sets of IDs
therein. If they differ, a full inventory is required. If they are
equal, no full inventory is necessary.

> a) it's a duplicate or
> b) the old file was moved here
> 
> I think it's necessary to do a full tree-inventory to distinguish these 
> cases.

So yes, I agree with you, when the precondition you stated is true. My
point is that you can detect whether or not a full inventory is
required, and proceed from there. I would expect the common case to be
that no full inventory is required.

Let me try to prove inductively that this scheme cannot result in a
corrupt commit. That is, a "get" of the committed revision would
construct a valid tree. The committer's project tree may in fact contain
errors during and after the commit, but they will not propagate to the
archive. The user will not be notified unless he tries to do a commit
involving them.

Assume that a get of the previous revision results in a valid tree, and
that you have a pristine/revlib containing that tree.

First you do an inventory using the selection on the project tree.
Errors may be detected here (e.g. duplicate IDs both within the
selection), in which case the commit will be aborted. If no error was
found, you apply the selection to the pristine tree and record the set
of IDs it contains (this could be sped up using the ,,index-by-name file
of a revlib). If the ID sets are equal, record any file modifications
and/or moves within the selection (as specified by the selection) into a
changeset, and ship it to the archive.

If instead the two sets of IDs differ, you may still be able to avoid a
full inventory, but you have a few choices about how to treat those IDs
in the symmetric difference:

  If an ID is in the pristine selection but not the project tree
  selection, you could either assume it's a delete (not very user-
  friendly), or inventory the project tree to find out if it's a rename.
  Errors from outside the selection may be detected in doing so, but
  they could be downgraded to warnings.
  
  If an ID is in the project tree selection but not the pristine
  selection, it's either an add, a rename, or a duplicate. You must
  inventory the pristine tree (or read ,,index from a revlib) to
  determine whether it is an add. If it's not an add, you can either
  assume it's a rename, or inventory the project tree to determine
  whether it's a duplicate.

Once you've determined the what to do with each ID, you can construct a
changeset and ship it to the archive.

So, all of the changes recorded in a commit, if applied to the pristine
tree, would result in another valid pristine tree, because exactly one
action was applied to each ID in the pristine (no change, rename, or
delete), one action was applied to each file in the pristine (no change,
modify, or delete), and a few unique IDs with their associated files may
have been added.

Of course, applying that changeset to the pristine is just an
implementation of get.


Now, not telling the user that their project tree as a whole is invalid
isn't very nice, but that seems to be the price for avoiding a full
inventory with selected commit.

-- 
Jason McCarty <address@hidden>