[Gnu-arch-users] Re: semantics of restricted mkpatch

[Denys Duchier]

Tom Lord <address@hidden> writes:

>     > >       ORIG TREE:                      tag     modified
>     > >
>     > >               ./dir-A                 T1      
>     > >                   ./dir-A/file-A      T2
>     > >                   ./dir-A/file-b      T3
>     > >                 ./dir-B                       T4
>     > >                   ./dir-B/file-c      T5
>
>     > >       MOD TREE:
>
>     > >               ./dir-B                 T1
>     > >                   ./dir-B/file-A      T2      yes
>     > >                   ./dir-B/file-b      T3      yes
>     > >                 ./dir-C                       T6
>     > >                   ./dir-C/file-c      T5
>[...]
> If your changeset records "T1: dir-A -> dir-B" but not "T4:dir-b
> deleted" then it does not apply cleanly to the ORIG tree (because the
> path ./dir-B is already in use).

Ah thank you!  I knew there was something fishy here, but I failed to
recognize it properly (I even tried to construct this very example,
and failed - how stupid of me).

>  If it _does_ include "T4 deleted",
> then it should probably also include "T6:./dir-C created" and "T5:
> file-c renamed" (so that file-c is not quietly deleted when the
> changeset is applied to ORIG).

agreed.

> Agreed.  (The current algorithm you are describing seems, as I've
> said, to not be integrity-preserving.)

Yes, I will rework it to make explicit the closure computation, and I
will further abstract limits matching so that we can implement more
agreable / powerful semantics e.g. with respect to the choice of ORIG
or MOD.

But first, I'll try to work it out of paper.

Thanks again for your comments.  These issues have become noticeably
clearer in my mind now.

Cheers,

-- 
Dr. Denys Duchier
Équipe Calligramme
LORIA, Nancy, FRANCE