Re: [Gnu-arch-users] Re: fixing and extending "selected commit"

[Tom Lord]

    > From: Robert Anderson <address@hidden>

    > Remember back in the day when the idea was that you had whole-tree
    > commits, period, and that was a good thing?  It was good because you
    > ought to at least have the option of running "make check" on the tree
    > before it gets committed (for example).  This whole "limits" idea takes
    > away the chance to have a look at and test the tree _in the committed
    > state_.  I think that's a bad thing.  Or at least, it's not typically
    > what I want.

    > What I'm suggesting is splitting "partial commit" into making a "partial
    > tree" and then using a full-tree commit.  This way, you always get a
    > unified look at the committed tree state, and you're free to run
    > what-changed to review the "partial" commit, or run "make check" or
    > apply whatever criteria you like to committed tree states.

Very well said.

The /best/ thing here is /not/ to focus on partial commit as a
performance hack -- but rather as a new bit of functionality.  It's
the meaning of the functionality, not a coincidence that it might be
"fast", that is the primary consideration.

You know, part of the issue here is that people hear about "copy a
tree" or some such operation, and think "Hey, that's too expensive!".

I don't mean to blow off such concerns.  Nevertheless:

Copying a tree is just about the second or third lightest weight
operation you can do to a whole tree (I'm putting a `find' traversal
and a `make a link tree' ahead of it, a simple `grep'-like traversal
just behind those).

So, you know, if your development environment is _so_ out of scale
with your tree that copying the tree is just too horrible to
complicate:  then perhaps either your environment is far weaker than
you need, or your tree is out of control.

I'm all for continuing to tweak arch to be faster and faster -- but
there is a limit to what we can do.  The recent appearence of
--hardlink hacks (which I _STRONGLY_ADVISE_AGAINST_USING_ in their
current state) illustrates that we're nearing the point of trading
robustness for speed -- a very uncomfortable choice.

At some point, it starts to be reasonable to switch from saying "arch
isn't quite up to that scale tree" to saying "arch is the canary in
the coal mine -- that tree is too big."

-t