[merge] tags in Branch

[Martin Pool]

Matthew D. Fuller wrote:
> On Mon, Feb 26, 2007 at 11:47:21AM +1100 I heard the voice of
> Martin Pool, and lo! it spake thus:
>> Here's an updated tags patch, which I would like to merge for 0.15.
> 
> First off, yay!
> 
> 
> Now, some things I came across in testing:
>
Thanks for testing it so promptly.

> - 'help tag' still says the tags are stored in the repo and apply to
>   all the branches in it.

Fixed.

> 
> - Too, the 'tag' help should probably explicitly state that giving an
>   already-used-here name will move the tag.

Done

class cmd_tag(Command):
    """Create a tag naming a revision.

    Tags give human-meaningful names to revisions.  Commands that take a -r
    (--revision) option can be given -rtag:X, where X is any previously
    created tag.

    Tags are stored in the branch.  Tags are copied from one branch to
another
    along when you branch, push, pull or merge.

    It is an error to give a tag name that already exists unless you pass
    --force, in which case the tag is moved to point to the new revision.
    """

> - init'ing a branch as experimental-branch6 creates the branch/tags
>   file, but upgrade'ing a branch to branch6 doesn't.

Thanks, fixed


> - The output of 'tags' doesn't put a newline after each tag, so the
>   name of the second tag is jammed up against the end of the revid for
>   the first, and my prompt is jammed up against the end of the revid
>   for the last.

(The problem with just writing automated tests is they don't have much
common sense...)

Fixed.

> - Neither does the output of 'tag' put a newline after its "created
>   tag XXX".  It kinda bugs me that 'created' isn't capitalized there,
>   but then 'added' isn't either, so...

Fixed


> - The 'tags' output also pushes the revid far enough over that it
>   wraps around to the next line.  Cosmetic, but annoying.

Changed so the tag name is just 20 columns

> - Doing a 'pull' doesn't reset tags.  Neither does 'pull --overwrite'.
>   Tags that were on the old branch are still around after it, even if
>   the two branches share no ancestry.

Yes, overwrite should probably clobber them.  I'm not so sure about pull
without overwrite.

> 
> - Moving or deleting a tag doesn't actually seem to be merged, only
>   adding.

That's correct; we can do it by explicitly setting the tags to '', or we
 can do a history-sensitive merge.

> The following is probably intended (or at least expected) behavior,
> though a little un-POLA:
> 
> - Moving/deleting a tag, without adding new revisions, leaves a
>   'merge' of the changed branch not knowing of anything to do.

I'm not sure I understand - do you mean that you need to merge to get
the changes, but merge won't tell you so?

-- 
Martin