Re: [Monotone-devel] A question about tags

[Daniel Carosone]

On Fri, Mar 14, 2008 at 09:31:27AM -0400, Jack Lloyd wrote:
> 
> Is it intentional / planned that tags in Monotone are database wide
> rather than branch wide? By which I mean, if two projects
> 
> net.randombit.test1
> net.randombit.test2
> 
> share a database, then tagging revisions in both of them as (say)
> '1.0' will cause all kinds of annoying conflicts (ambiguous selector
> expansions, etc)

Yes, it is, coupled with the recommendation/expectation that tag names
are usually more descriptive and at least a little less likely to
collide.  Eg, 'monotone-0.39' rather than '0.39'.  Note that this
expectation holds elsewhere, too; these kinds of tag names are
commonly used in CVS and other systems.

> This seems really bad/surprising to me... in particular because
> Monotone requires a single database for servers... so two projects
> that have no knowledge of each other and acting non-maliciously can
> cause conflicts such that they can't both be reasonably used from the
> same db.

I'm not sure it matters for the server, it's an issue for someone
pulling from the server if they take all the unrelated projects
collectively.  Even then, it's a convenience issue when writing
selectors; as you note, the solution to ambiguous selectors is to
disambiguate by adding terms.

Note that you can issue the same tag twice on the same branch, too,
that can be even more confusing.

> Is this just an implementation artifact, or is it considered the Right
> Thing to do?

In some ways, it's a little of both.  Tags are just certs, and it's
been left open to the user to combine certs and find usage patterns
that make sense, whether the cert name is 'tag', 'branch', or
something else.  This freeform combination is certainly considered the
Right Thing, the specific implications for "tagging" behaviour
vs. expectations from other systems are currently a mix of
implementation artifact and learning the "monotone way".

Tags don't have to be unique, and maybe someone will find a way to use
that property sensibly.  Think about tags in the context of a blog
rather than 'tagging releases'; someone might tag revisions with
'bug', 'fix' and/or other annotations that describe something about
the nature of the change.

However, there is talk that maybe what we currently do is not such a
good fit for what people expect an annotation called 'tag' to be.
Certainly, the annotation above could be done with another cert name,
though less conveniently because 'tag' comes with a nice t: selector
syntax.

As part of the policy branch concept, we can keep project metadata in
versioned, structured text files.  This could include a tags file
listing names and revision id's.  This allows moving tags, and could
prevent multiple tags with the same name in the same project.  It's an
open question how this mechanism would combine with selectors.

In CVS, tagging was hard and slow which discouraged general-purpose
convenience tags, and we needed tags for several things - not just
imports and releases, but also branch (divergence) points and merge
points.  In monotone, divergence and merging is handled much better by
explicit ancestry.  This really just leaves 'release tagging' of the
traditional uses, and perhaps that's a specific enough requirement to
be a dedicated first-class mechanism in policy branches.  However, we
should also see what other uses can come from more general-purpose
tagging/annotation, now that it's ~free.

--
Dan.

pgpDAFUG3e2Ux.pgp
Description: PGP signature