monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Announcing "m7", a monotone front-end... which adds


From: Richard Levitte - VMS Whacker
Subject: Re: [Monotone-devel] Announcing "m7", a monotone front-end... which adds revision numbers!
Date: Tue, 27 Sep 2005 15:16:54 +0200 (CEST)

In message <address@hidden> on Tue, 27 Sep 2005 05:45:39 -0700, Larry Hastings 
<address@hidden> said:

larry> As far as not using tag certs for the ids, I don't really
larry> agree.  Ignoring the specific argument cited above, are there
larry> any other reasons they /shouldn't/ they be tags?  After all,
larry> this revision number tag that *m7* writes out is "a symbolic
larry> name given to a revision", and that's the very /definition/ of
larry> a tag cert, straight out of the *monotone* documentation.  I
larry> see it as entirely appropriate.

Hmm, maybe this is a question of use case.  I use tags as a symbolic
name given to a revision *to signal an event*, for example to tell
everyone what revision I used to build a specific release (as it's
currently done with monotone itself).  If there are suddenly tags on
*every* *single* *revision*, they immediately lose their value in my
view.

larry> There's also a near-term logistical problem.  Right now, if I
larry> used an arbitrary other cert, I wouldn't be able to easily get
larry> a list of them out of *monotone*.

Hmm, the basic functionality is already there with the selector
c:{certname}[={certvalue}].  So whenever you want to find a specific
revision through a m7 number, the corresponding monotone command would
be this (if you use "my-tag" as cert name):

        monotone automate select c:m7-tag=lch:penguin:7

larry> Tags I can list with *monotone list tags*.  But arbitrary certs
larry> are unretrievable unless either you know something about them
larry> (like what revision id they are joined to) or you're willing to
larry> delve into SQL.  Though I'm sure if I whined enough /
larry> contributed code, we could have a nice high-level interface for
larry> querying for these in the next release.

for x in `monotone automate select c:tag='monotree*'`; do monotone list certs 
$x; done

Yes, the output could look nicer, but it shows that it's quite
possible to list arbitrary certs using current monotone commands and a
little bit of filtering.  If you want, I can probably create a quick
perl hack (I need a little more time with Python, as I'm quite a
newbie with that language, still) that outputs arbitrary certs in the
same nice way as "monotone list tags".

larry> As for not wanting to see untold kajillions of tags, I see that
larry> as a user-interface issue.  The solution is better tools at
larry> dealing with arbitrarily large collections of tags, not telling
larry> people "oh, don't use a tag there! you'll clutter up *monotone
larry> list tags*!"  For instance, *m7 list tags* could weed out all
larry> tags that conform loosely to its default tag specification.  Or
larry> only show you tags from the last month, or six months.  Or
larry> both.

OK, I've two (probably more, but these are the ones I can express
right now) problems with that:

1. it makes special cases of tags.  So far, a tag is a tag is a tag.
   What you propose is that a tag is a tag... unless it looks this
   way.
2. it assumes that everyone will use m7, and completely ignores the
   possibility of a mixe environment, where some use monotone directly
   (I've no interest in localised revision numbers, so I'll probably
   be one of those if m7 is used with the monotone repository) while
   others use m7.

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis




reply via email to

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