Re: [Gnu-arch-users] Re: -L option for tag?

[Tom Lord]

    > From: Miles Bader <address@hidden>

    > Tom Lord <address@hidden> writes:
    > >     > BTW, is it alright to use `tag' to create _occasional_ tagged
    > >     > versions in branch, e.g., base-0 = tag, patch-1 = patch, patch-2
    > >     > = patch, patch-3 = tag, ...?  This seems convenient in some
    > >     > cases, but I vaguely recall a warning against it somewhere.

    > > However, I wonder if in 9/10 of your occaisional cases, you wouldn't
    > > rather `get' the thing you would tag, `sync-tree' with the version you
    > > want to commit to, then commit.

    > My reason for wanting to do this is this:  I'd like to keep around
    > branches for my own use (e.g., my `x' branch), whose contents are
    > eventually merged back into my main branch, and basically the branch is
    > then defunct.  However later, I'd like to do the same thing again, and I
    > don't particularly want to change the version number (which would
    > probably be the `kosher' way to do this), e.g. reuse the same
    > branch/version.  In this case, it's likely that the delta between the
    > last patch of the previously defunct `x' branch and the new hip `x'
    > branch is pretty large; since really I just want the new patch level to
    > be a straight copy of the main branch, a tag/link is the obvious thing
    > to do.

Bah.   It sounds like you are wanting to use `tag' to save some
archive disk space.   I think that's silly.   It _should_ at least
_fairly_ silly to you now and, in 2-3 years, when you have a better
box, it should be completely silly.

Don't use `tag' just to avoid a large `changeset', imo.


    > BTW, what's the problem with doing replay or whatever in this situation?
    > It seems like a replaying a continuation changeset in an existing
    > project tree should just delete the entire project tree contents, and
    > then checkout new sources; does it not do this?  

No, it doesn't.   There's two parts to a continuation revision.
There's the pointer to some other revision -- the revision named in
`tag' -- the revision named in the archive's CONTINUATION file.   And
then there's a changeset on top of that.

`replay' replays the changeset and ignores the CONTINUATION file.

As a vague sort of suggestion:  the design space of "merge operators"
is huge.   Really, really, huge.   and there's no single one, as far
as I can tell, that always does The Right Thing -- it's more like you
have a toolbox of merge operators and have to have the skill to pick
out the one you want.    So:  if you want something that resembles
replay but differs in some ways -- well, that's how we got
`--skip-present', for example.


    > I guess one oddity would be that such a changeset would not be
    > (easily) reversable, but I'd think that's not usually a problem.

There is no context-independent "usual problem" wrt merge operators,
as far as I can tell.   That's why the tutorial has the structure it
does.   With a little bit of constraints, _then_ "usual problems"
arise and have solutions:

The tutorial describes particular disciplined patch flows (but doesn't
call them that since people balk at the mention of "discipline").
So, you get "The update/commit Style of Cooperation" and "Development
Branches -- The star-merge Style of Cooperation" and (not in the
tutorial but mentioned on the list): "Using Multiple Branches Yourself
-- the Prism Merge Style of Hacking" and "Idempotent Merging -- The
--skip-present Style of Cooperation".

So, if you have "The Miles Bader Style" and need some options/commands
for it .......


The Maritial Arts of Revision Control,
-t