David Bustos <David.Bustos at sun.com> writes: > I started a project gate based on ON. I want the gate to track numbered > builds. First I cloned onnv-gate and rolled it back to the most recent > build (onnv_78 at the time). This didn't work because changes formed > a new head and hg recommit refused to operate on such a workspace. So > then I cloned onnv-gate with "-r onnv_78", and that worked well. Except > that Mercurial brings over all the changesets up to the tagged one, > which doesn't include the changeset which creates the tag, so while the > gate was at onnv_78, it didn't actually contain the onnv_78 tag. > I found this annoying. So I think going forward when I sync to the next > build, I'll include the changeset which creates the tag. > > So I think there are two questions here: > > - Will including the tagging changesets set me up for some problem > later? Is there a reason I shouldn't do this?
I don't see any problem with that at all. > - If it's ok, should I file an RFE for Mercurial to allow me to > specify the changeset which creates a given tag? That is, right now > in order to pull the changeset which creates the onnv_79 tag, I have > to look up its revision number or hash. It would be a lot easier to > say "onnv_79+1" or to have an option which Mercurial understands to > mean "the changeset which creates this tag". I imagine the latter > might be not be generic enough since a changeset which creates a tag > might include other changes, so the fact that we create a tag-only > changeset is a local ON policy. It would be nice to see the +<N> feature, I agree. However, as said in the other mail, it won't solve your problem in the general case. For what it's worth, the only problem I know of with tags relates to tags you create in the child. See bug #356 "cdm recommit needs to cope with the tags it may be trashing" (http://bugs.grommit.com/show_bug.cgi?id=356) -- Rich
