[merge] tags in repository

[Gustavo Niemeyer]

Hey Martin!

> > This adds tags stored in the repository, and visible across branches
> > in that repository.  Adding a tag doesn't require a commit.  Tags
> > are

Yay! Tags are coming! ;-)

> > This adds tags stored in the repository, and visible across branches
> > in that repository.  Adding a tag doesn't require a commit.  Tags
> > are 'global' across projects so people should use them appropriately
> > - eg putting the project name at the start of the tag like
> > 'bzr-0.14'.

That sounds a bit unusual at first glance, but I can see value in
being able to get the same consistent set of tags accross several
branches in the same repository.

> >1) Tags are not versioned, rather they are just current points in
> >time.  I know one of the big troubles we had was trying to handle
> >versioning.  At least it caused a lot of debate.
(...)
> That said by putting the policy in the repository there is some scope
> to do something more complex - this doesn't record who set the tags or
> when, but you could.

Or, maybe more importantly, why.  That's one of the pros of committing
tags.  The "why have you tagged"/"why have you moved the tag" question
is answered in the repository.

> That's true, thanks for pointing it out.  I had wanted to also allow for 
> existing values to be either preserved or overwritten but just dropping 
> them is not a good default.

If tags are always "updated" (in Python's dict sense) on merge,
how are tags ever removed?  Won't they revive once I merge
from someone else that still has the old tag I'm trying to kill?

> If we want to merge them then I think we should treat it as a scalar 
> merge, which would require storing a graph, not just a list.

Doesn't that mean we'd be basically committing tags, but with a
different commit timing than the rest of the repository?

> >So one possibility would be to have the default "copy_tags_to" be:
> >
> >  tags = self.target.get_tag_dict()
> >  source_tags = self.source.get_tag_dict()
> >  for k,v in source_tags.iteritems():
> >    tags.setdefault(k,v)
> >
> >Which means that it will pull across any tags that don't already exist,
> >but it won't touch ones that do.

It seems this would make moving and removing tags a problem.

> Yes, that's what I thought by default.  I don't mind holding off on
> this until that is done -- it won't take me long -- but I did want to
> show something.

Thanks!

> As an interface I thought we would start by giving a notice to the user 
> when there is a difference:
(...)
> You could then pull with --overwrite-tags, or use a copy-tag command to 
> pull it across.
>
> For uncommit we do actually talk interactively to the user if possible 
> (if there's a tty), and that might also be reasonable here.

Both sound like good ideas.  I also wonder about removing
tags in that context though.

> I am not sure what we can do to help the user make a good decision about 
> where the tag *should* be.

This sounds like a problem where revision control could be
used again.  Bazaar is able to do a good job helping the
user in situations much more complex regarding the state of
things along one or more change lines.  Tracking changes in
a simple key => value dictionary, where we're able to have
a well defined and documented merge behavior, should hopefully
be easier.

-- 
Gustavo Niemeyer
http://niemeyer.net