Re: [Gnu-arch-users] configs are too weakly coupled

[Tom Lord]

Acked for the bug database.

As a straw-man, how about:

   % tla config-status CONFIGNAME

Report the existence of extra or missing required subtrees and
subtrees whose tree-version or patch-level is wrong.

   % tla set-aside-extra-subtrees CONFIGNAME

Move all subtrees that don't fit CONFIGNAME to a ./+saved-trees
subdir of the top-level dir of the tree.

   % tla restore-missing-subtrees CONFIGNAME

Fill the missing parts of a config in, taking trees from ./+saved-trees
if they are there.


Out of those, it should be possible to synthesize a very nice:

   % tla switch-config FROM TO

which is:

   % tla set-aside-extra-subtrees TO
   % tla set-restore-missing-subtrees FROM



   % tla in-each-config-subtree CONFIGNAME SUBCOMMAND [...]

As in:
                % tla in-each-config-subtree CONFIG replay

with options to save output and error output in files (in each
subtree), stop at the first error or run in all trees in spite
of any errors, etc.


-t






   From: "Robert Anderson" <address@hidden>


   There is a recurring problem in my development group that stems
   from the way that there is really no strong connection between
   configs and the trees built from them.

   It goes something like this:

   Devguy: "I built after your merge and there's a link problem now."
   Me: "Are you fully up-to-date?  It builds for me."
   Devguy: "Yes, everything is fully updated.  No luck."

   The problem is invariably that a config file has been changed,
   and the devguy is unaware of this and is confused and frustrated
   that he can't get up-to-date by issuing "update" commands. 
   Frankly, I think he's right to be.  You shouldn't always have to
   check out from scratch, or sift through commits wondering if
   someone changed a config file, manually tweaking your trees if
   there was, or write your own hacky scripts that verify the
   consistency of configs and tree layouts.  It ought to be a
   one-off operation to verify that a config is fully checked in on
   the one side, and a one-off operation to bring the config up to
   date on the other, or verify that it is.

   Maybe this is something the baz guys can think about.

   Bob




   _______________________________________________
   Gnu-arch-users mailing list
   address@hidden
   http://lists.gnu.org/mailman/listinfo/gnu-arch-users

   GNU arch home page:
   http://savannah.gnu.org/projects/gnu-arch/