monotone-devel
[Top][All Lists]
Advanced

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

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


From: Nathaniel J. Smith
Subject: Re: [Monotone-devel] project_t , and preparing for projects / policy branches
Date: Sat, 13 Jan 2007 21:28:55 -0800
User-agent: Mutt/1.2.5.1i

On Sun, Jan 14, 2007 at 12:18:44AM -0500, Ethan Blanton wrote:
> Nathaniel J. Smith spake unto us the following wisdom:
> > 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.

If you're always committing things on the wrong branch, that sounds
like a pretty serious problem with the branch UI, that we'll need to
fix eventually regardless of what happens to tags.

Of course, I guess you're thinking of how svn tags work, where if you
check out a tag then you are left with a workspace that you can commit
to, and commits will modify the tag, rather than the original branch
that the tag is off of?  That sounds like exactly the same problem
that I identified.  Are there any others?

> 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.)

Yeah, sure -- just exploring the idea a bit (and there's _way_ more
exploration to be done before we actually finish migrating to the
glorious future of branch-namespace-in-policy-branch, let me tell
you...).

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

The likelihood of accidentally typing 'mtn branch -r <rev>
frobnicator-release-2.0.3' seems pretty low to me too :-).

-- Nathaniel




reply via email to

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