Re: [Gnu-arch-users] Re: Re-linking to revlib implemented

[Tom Lord]

    > From: Samuel Tardieu <address@hidden>

    > >>>>> "Tom" == Tom Lord <address@hidden> writes:

    > > I kind of like this particular implementation-exposing aspect of the
    > > interface to the functionality just because it's realistic -- people
    > > who get why it's part of "changes" will have a better understanding
    > > of how arch works and thus be more effective users of it.

    > I don't like it, because each time I do "tla changes" I'll be tempted
    > to add "--link" just in case I didn't do it after a commit, update,
    > replay or star-merge. Or I won't, because I'll (wrongly) think I've
    > done it already.

But see, to me, those sound like examples of what I'm talking about.

It's generally not going to be critical to anything to always have
your tree in a maximally linked state.  Therefore, I'm reluctant to
change commands such as update to unilaterally do the extra work of
relinking.

The next possibility is to add --link options to every command that
you think might sometimes be an occaision where you want to relink.
So you can `commit --link' or `update --link' or even `replay --link'.
I'm not too thrilled with that idea because it's an example of bloat
and because the "optimal" --link strategies for those will differ and
inevitably people will be asking for those optimizations and thus
creating more opportunities for bugs.

And that leaves explicit management: user runs a separate command to
relink.  The work done by `changes' is just about exactly what such a
separate command needs to do -- relinking is just a small additional
step to that.

So, yeah -- you're saying "I don't like it because if I want relinking
to work really well I have to think about when to do it" and I'm
saying "I like it because it means that if you want relinking to work
really well you'll have to think about when to do it."

-t