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

[Justin Patrin]

On 9/27/05, Larry Hastings <address@hidden> wrote:
>  Richard Levitte - VMS Whacker wrote:
>  for x in `monotone automate select c:tag='monotree*'`; do monotone list
> certs $x; done
>
>  Ah, so they could be pulled out of monotone without resorting to SQL today.
>  Thanks!  (It would be an O(N) operation, as compared to an O(1) operation
> with monotone list tags, but it should still be fast enough that the user
> wouldn't notice.)
>
>
>  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.
>
>  I don't see how these tags are "special cases".  My intent was that they be
> normal tags, just like any other tag.  The only thing arguably "special"
> about them are that
>
>
> m7 provides a special command-line shortcut to refer to them,
> m7 tannotate can recognize and abbreviate them, and
> there are a lot of them.
>  But they work just like normal tags, because they are normal tags.  I can
> say monotone cat revision lch:flu:7 if I like, works fine.  Indeed, m7
> currently relies on that fact; the :<number> shortcut simply gets expandsed
> into t:$username-$computername-<number> before it runs
> monotone.
>
>
>  2. it assumes that everyone will use m7, and completely ignores the
>  possibility of a mixe environment,
>
>  As with your previous point, I fail to see how this approach "ignore[s] the
> possibility of a mixed environment".  There is nothing in m7's design or
> implementation that would preclude interoperating with non-m7 users; m7 does
> nothing that breaks monotone's data model.  You continue to use monotone
> directly, and I could sugarcoat it with m7, and we could push and pull
> between our databases without incident.
>
>  If you're really just restating your earlier point about "well, but there'd
> be a lot more tags now, and that would be inconvenient", then my reply is
> again "that's a user interface issue".
>
>
>  Let me be clear: I am hardly opposed to changing these tags to custom
> certs.  Indeed, that could offer its own advantages.  But I am curious about
> the reaction of the general monotone community.  I am now well acquainted
> with Mr. Levitte's opinion; what do the rest of you think?
>

I agree with Richard. Tags are meant to be used for special cases
where you want to keep track of a set of revisions, such as released
versions. If you add tags which happen for every revision then tags
become far less useful. A revision is a revision, not a tag. Certs
would be much more appropriate for this. As shown it can be
implemented as-is and future additions to monotone can make it easier.

Oh, and as for O(1) vs. O(n) I think that's a very false assumption.
True, you're going to start more processes, but monotone itself has to
do internal things to deal with these commands. Unless you check
monotone's internals for how it handles the commands calling one O(1)
and one O(n) is a misnomer. Likely they're something like O(n)
O(nlogn)

--
Justin Patrin