gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] [arch advocacy] Games from Within: litmus test for


From: Tom Lord
Subject: Re: [Gnu-arch-users] [arch advocacy] Games from Within: litmus test for revision control
Date: Wed, 30 Mar 2005 08:15:09 -0800 (PST)


   From: Jan Hudec <address@hidden>

   >    The problem here is, that the indices only contain full path from root
   >    to the files and their IDs, but not IDs of the parent directories.

   > You're ahead of me in diagnosis, if you are right (and I'm working
   > mostly on other things for the next few days).

   Looking at orig-files-index and mod-files-index (and respective -dirs-)
   in a changeset, that adds a file, I only see 2 columns: the full name
   and id of the file. Since there is no other ID and since the dirs inices
   are empty (so the ids can't be infered from there), I see no way to find
   the ids, which is how I came to the above conclusion. Perhaps I am missing
   something.

Suppose that one line in `mod-*-index' contains an entry for a
newly added file and another line contanis an entry for the dir
where that file was added.   Since both are in the `mod' tree, `dopatch'
can figure out (on the basis of paths) the id of the directory in which
the new file was added.

E.g., given MOD entries:

        a/b     x_b_id


        a       x_a_id

where `x_b_id' is a new file or dir, we know that `x_b_id' wants to be
added in the directory whose id is `x_a_id', no matter what that
directory happens to be called.

-t





   > One problem might be, as you say, that the parent dir ids are omitted
   > from the changeset indexes.  They are supposed to be there.

   > The other problem might be that, even if those are there, the code
   > in `dopatch' isn't using them correctly.

   > The same damn bug (by effect, not necessarily cause) occured in `larch'.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]