Where should we put our tags?

[Matt Mackall]

On Wed, 2010-01-13 at 02:50 -0800, William Roberts wrote:
> 
> 
> Dirkjan Ochtman wrote:
> > 
> > That said, I'm with Greg on the fact that tagging on a separate branch
> > probably isn't that useful, but it kind of depends on the rest of your
> > workflow (e.g. do you use named branches or separate clones or
> > named-branches-in-separate clones, do you merge everything back into a
> > default-like branch or not).
> > 
> 
> Simon could have put in some links to show you what we mean - for example
> 
> https://developer.symbian.org/oss/MCL/sf/app/webuis/graph
> 
> We use named branches (in this case default and "RCL_1"). These branches
> never converge again, but we prefer to use a single repository rather than
> having a repository per branch because our codebase is already divided into
> 150 repositories and we don't want to multiply that further.
> 
> We normally build from the tips of the branches, and tag once we get the
> build into good shape: this is what leads to the tagging commits being later
> tagged themselves.
> 
> We also have the problem that we get regular "code drops" from another CM
> system, currently in a strictly "1-way" fashion: look for commit messages of
> the form "Revision: 2009xx". We limit the damage of this by making sure that
> each drop has the previous drop as the parent, but that means that it never
> notices our tagging. 

Yeah, normally you'd always keep your tag commits inline with your
commit flow. That way you don't end up with stray heads, which I assume
your weird "merge tags" csets are intended to fix.

If you're going to do things that weirdly, then yes, you might as well
put tags in their own branch. But I wouldn't recommend it in general.
Among other things, your tags won't get pulled in a clone -r branch.

But I'd really suggest you simply keep your tags inline and adjust your
importer to treat tag cset descended from rev x as equivalent to rev x. 
I'm fairly confident the resulting graph will be a lot less confusing.

Also note that this problem has nothing to do with the fact that tags
are stored in our weird .hgtags file (principle: all editable data lives
in working directory), but instead with the fact that tagging creates
full first-class commits in the history that affect the history graph in
the same way as other commits (principle: tagging events should be
tracked like other changes).

-- 
http://selenic.com : development and support for Mercurial and Linux