monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: Best practice using monotone


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Re: Best practice using monotone
Date: Thu, 24 Aug 2006 19:30:32 -0700
User-agent: Mutt/1.5.12-2006-07-14

On Thu, Aug 24, 2006 at 06:36:10PM +0100, Andy Jones wrote:
> I know it's a pain but really, ideally, this is a bug.  Either the
> system should cope with multiple identical tags, or it shouldn't allow
> you to make them.    Principal of least astonishment.

It does cope -- it says "there are multiple revisions with that tag,
here's a list.  which one did you want?" :-)

As you note, disallowing it is physically impossible (given the basic
distribution model monotone assumes).

> Anyhow, that narrows it down - I have to arrange for a branch for each
> release I want to "sticky".

Sure.  Note that what's really going on here is:
  tagging rev R with tag T
    --> issues a cert against revision R, with name "tag" and value T
  creating a branch B, with rev R as the first member
    --> issues a cert against revision R, with name "branch" and value B
There isn't much difference :-).

Note also the b: selector, which is exactly equivalent to the t:
selector (including how it copes with there being multiple items with
the relevant cert), and they're both just special cases of the generic
c: selector.

Branches do come with the fancy h: selector. h:foo is basically
a short form for
  mtn automate select b:foo | mtn automate erase_ancestors address@hidden
and so you can get the same effect for tags with
  mtn automate select t:foo | mtn automate erase_ancestors address@hidden
More verbose than h:, though, definitely.

-- Nathaniel

-- 
"...All of this suggests that if we wished to find a modern-day model
for British and American speech of the late eighteenth century, we could
probably do no better than Yosemite Sam."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]