On 03.02.2007, Brendan Cully <brendan@xxxxxxxxxx> wrote:
> On Friday, 02 February 2007 at 20:56, Jakub Narebski wrote:
>> For example you are on branch 'master', you tag current release
>> e.g. v1.3.4, then you checkout branch 'devel'... and you don't have
>> v1.3.4 tag available unless you merge in .hgtags from 'master'.
>> At least from what I understand of Mercurial tags behaviour.
>
> This would be bad, if it were true.
>
> $ hg up devel
> 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
> $ cat .hgtags
> 6acda9aa5d8c621b3db2f2daab878d8de726d227 base
> $ hg tags
> tip 4:b1f003583d8e
> v1.3.4 2:87e43e86318f
> base 0:6acda9aa5d8c
The above sequence of commands is not enough to reproduce the situation
I want to talk about, namely situation (repository structure) as in
below:
/-\
1---a---2---3---T---t---b .... 'master' branch
\
\-2'--3'--c .... 'devel' branch
where 'a' is branching point (merge base) of 'master' and 'devel'
branches, 'T' is tagged changeset (revision, commit), 't' is commit
where .hgtags with 'T' tag was committed. Changesets (revisions)
'b' and 'c' are tips of 'master' and 'devel' branch, respectively.
If .hgtags was an ordinary file, then at revision marked in above
graph as '2' it wouldn't have tag 'T'. Documentation (Mercurial
HOWTO to be more exact) tells that hg uses .hgtags version from the
tip. But when we are at branch 'devel', the version from the tip
is version 'c' without 'T', not version 'b' with 'T'... if .hgtags
would behave as described in documentation.
It looks however (if what you say above is true also for the situation
as in above graph, i.e. when at 'devel' branch we have 'T' in .hgtags)
that Mercurial always uses _latest_ version of .hgtags file (as in
external wall time, having notihing to do with the history as
represented in repository). But then we cannot say that we can merge
.hgtags file, so it is probably not the case. It is also contrary to
what I gathered from documentation.
If above was true, i.e. .hgtags doesn't behave at all as normal file in
working area, then what the heck it is doing there, and not somewhere
under .hgtags!?!
> As mentioned before, hg has local tags which sound an awful lot like
> git tags.
Git tags can be propagated. hg local tags cannot be propagated. hg tags
"in history" always are propagated.
> It also has properly versioned tags.
Reusing in-tree version control to version tags is IMVHO not a good
idea. Git has reflogs if you truly need to have history of tags.
> And, by the way, if you
> push a branch, you only push the tags that were committed on that
> branch. Furthermore, you can push based on a tag name that isn't
> committed in the branch you're pushing.
It seems awfully complicated.
> I think the "globally global"
> nonsense elsewhere in this thread may be a result of not understanding
> this.
>
> I'm probably done with this thread too. There's too much ignorant
> speculation to make it very productive.
--
Jakub Narebski
Poland
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html