[merge] tags in repository

[Martin Pool]

On 23 Jan 2007, Gustavo Niemeyer <gustavo at niemeyer.net> wrote:
> Hey Martin!

Hi Gustavo, thanks for commenting.

> > >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.

We could certainly add some attributes to the tags: who set them, when,
and an optional message.  I think in most cases people won't have a
message beyond "release bzr-0.14", but it may be useful sometimes.

> 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?

Yes we'd previously discussed adding an explicit 'deleted' marker.

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

Well, we would be constructing a new versioned graph, and would have to
deal with presenting merge conflicts between them, representation of
unresolved conflicts and so on.  We would avoid actually running the
commit command or recording the tree state when the tags change.

-- 
Martin