Re: [Gnu-arch-users] [BUG] FEATURE PLANS: selection by ID

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > Tom Lord wrote:

    > > For example, suppose that we have the rule:

    > >         (b ("./include" (id "i_x_header_file")))

    > > Suppose that in the tree we're looking at, the file with the id
    > > "i_x_header_file" is at the path:  "./include/X11/basic/x.h".
    > > Then the rule is rewritten:

    > >         (b ("./include" "X11/basic/x.h"))

    > > and is therefore equivalent to:

    > >         (b "./include/X11/basic/x.h)

    > I don't understand why you'd translate the ID into a filename.  Wouldn't 
    > it be better to operate on IDs?  Since IDs are preserved across renames, 
    > you wouldn't have to worry about trying to commit half a rename.

Remember that the translation happens when the selection is being
evaluated against a particular tree. 

Some examples based on this tree:

        NAME                                    ID

                        ORIG TREE
        ./
          ./a-headers                           x_foo
            ./a-headers/foo.h                   i_bar
          ./b-headers                           x_baz

                        MOD TREE

        ./
          ./a-headers                           x_foo
          ./b-headers                           x_baz
            ./b-headers/foo.h                   i_bar


The selection:

        (n (id "i_bar"))

is sufficient to commit the rename.   Against ORIG it matches:

                 NAME           ID           MATCH TYPE

            ./a-headers/foo.h   i_bar        n

and against MOD it matches:

            ./b-headers/foo.h   i_bar        n


and that's fine if what I want to do is commit that rename.

This selection:

        (b "./b-headers")

says "I just want to commit everything under "./b-headers".
In MOD it matches:

            ./b-headers         x_baz        b
            ./b-headers/foo.h   i_bar        b

but in ORIG it matches only:

            ./b-headers         x_baz        b


and so it contains "half a rename" and can not be committed.
That's a feature -- it let's me enforce branch policies 
such as "on this branch, nothing outside of ./b-headers 
may be modified."

If I wanted to make an exception to my policy and allow the rename,
I could use:

        (selection (b "./b-headers)
                   (n (id "i_bar")))

or

        (selection (b "./b-headers)
                   (n "./a-headers/foo.h"))

(or many other variations).


(That's roughly the basis of the feature idea I haven't 
written up yet -- a kind of file locking so that different
branches of a mainline can claim non-overlapping ownership
of parts of the tree.   In very structured and hierarchical
projects, such as EDA or web content design, locking is 
a desirable feature, afaict.   Using selections and per-branch
rules, we can support hierarchical locking --- a particular team
can lock a N directories, individuals on that team can lock
specific files within those directories.)

-t