Re: [Monotone-devel] project_t , and preparing for projects / policy branches

[Ethan Blanton]

Nathaniel J. Smith spake unto us the following wisdom:
> > Also, the mentioned get_tags() returns a set of new "tag" objects. The
> > code that used it wanted to know the key used for signing the tag, but I
> > don't think it's at all certain that tags will remain implemented as
> > certs (putting them in the policy branch should allow them to become
> > more interesting). So, just returning a set of certs probably wouldn't
> > be good.
> 
> Yeah, tags are an interesting question.  We should probably even
> consider simply throwing them out altogether -- the only thing I can
> think that's actually different between tags and (what monotone calls)
> branches is that if you do
>   mtn co -rt:foo
> you don't want monotone to guess that the workspace should have its
> default branch set to "foo", but rather to whatever "real branch" the
> revision is in (if there is one).

Except that tagging is explicit, whereas a 'mtn ci' in the wrong
workspace or with the wrong branch name set from some previous
command is really easy to do.  This is one of the bigger problems
I have with svn -- that there is no such notion of tags.  I strongly
support the retention of an explicit tagging feature in monotone, even
if it is *technically* a redundant feature, because it is not socially
or practically a redundant feature.  (A blessed type of revision cert
could of course be the same way; some sort of "don't auto-update me"
flag.  But at that point, call a tag a tag.)

The likelihood of accidentally typing 'mtn tag -r <rev>
frobnicator-release-2.0.3' is pretty low.  ;-)

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764

signature.asc
Description: Digital signature