Re: [Gnu-arch-users] Re: <<< conflict markers

[Tom Lord]

    Aaron:
    >>> If we ever want tla to behave properly when tagging and commits are 
    >>> mixed, 

    Tom:
    >> Stop there.  There's different values for "properly" there.

    > I disagree about that.  I can't imagine circumstances in which
    > it would be desirable to apply unrelated patches to a tree.  And
    > if there were, surely one could do it with replay --list or
    > something.

I don't have much difficulty making up eccentric uses for it but I'll
skip that for now.   

Instead, look at what "ancestry-following update" should mean.  Let's
suppose, though, that what we have is a situation like:


                       base-0           ; a tag or import revsision
                       patch-1
                       patch-2          ;\
                       ....             ; } all others are commit revisions
   my project tree --> patch-K          ;/
   is uptodate w/      ...
   patch-K             patch-N          ; a tag revsion of 
foo--bar--1.0--patch-Z
                       ...
                       patch-X          ; (commit revision)


What, exactly, should a hypothetically ancestry-based update do if I
run it in my project tree?  Should it do (the equivalent of):


        undo patch-K
        get --clobber patch-X
        redo


or:

        undo foo--bar--1.0
        get --clobber patch-X
        redo

(or, something else entirely?)   And, if the latter, does it matter if
I'm uptodate with foo--bar--1.0--patch-(Z-2) but
foo--bar--1.0--patch-(Z-1) is a tag revision?

And, to know that certain optimizations _don't_ apply, `update' will
have to get the revision type of each patch-K+1...patch-X.

So, both for predictability and performance, namespace-based update is
the way to go.   More complex merging needs should be handled by a
flexible `super-merge' command or by scripts.


    >> It may be desirable to permit both options but it is essential to
    >> provide the option of using namespace relationships.

    > If you like.  AFAIK, there isn't any support for ancestry-based replays 
    > at the moment. 

Right, and that's pretty much by design.  Namespace-based
history-sensitive merging is fast and simple but sometimes fails to
provide some magic you thought you expected.  Ancestry-based
history-sensitive merging is slower and complex and whether or not it
can achieve the magic you are looking for (other than in isolated
special cases) is a research problem.  (A research problem with a
known outcome: it can't provide the magic but maybe you can make a
better approximation than the last guy.)


    > And personally, I'm lukewarm about mixing tags and commits.  But
    > I feel they should either be supported or forbidden.

I have a slightly different attitude:

~ Simple things should be easy.
~ Hard things should be possible.
~ The operation of each subcommand should be easy to explain.
~ Operations should not be forbidden just because you can't see why
  someone would want to do it.

If, following those principles, you wind up with something that
happens to be useful for revision control -- then, that's a win.  What
you wound up with is probably _very_ useful for revision control.

In this case, `update' (as it stands) makes a simple thing easy (while
other commands make harder merges possible).   It is easy to explain
what update does.  

And `tag' and `commit' make something simple to do easy and they too
are easy to explain.   It would be an arbitrary restriction to forbid
mixed-commit/tag versions so we don't do that.   (And, since I've
sometimes used them and seen other people use them, I'm very
comfortable with that.)



    >>> So we need to let go of the idea that replay and update are related, or 
    >>> else make replay follow ancestry.

    >> Wrong.

    > Right, as far as I know.  Update is an ancestry-sensitive three-tree 
    > merge.  Replay just happens to work like build_revision () in the common 
    > case.  It's not that one's disposable, it's that they're not related.

Update can be understood as any of a number of combinations like:

        undo + replay + redo
        what-changed + get + dopatch
        undo + delta-patch + redo
        get + delta-patch

etc.   I think that when users get how all these commands relate that
makes them more effective users.   Trying to hide a lot of black magic
in the guts of `update' is just going to create another generation of
users for whom revision control is a mysterious black-box.

-t