Stephen Lau <stevel at opensolaris.org> writes: > David Bustos wrote: >> 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? >> > It shouldn't. > As long as your changes are based off the tag-changeset, they'll still > all be in one branch rather than creating a new head. >> - 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. >> > Yeah - I too have always found this mildly annoying. The trickier part > I recall is that you could conceivably diverge where onnv_79 is the > divergence point and have multiple branches from there. So "+1" is hard > to define in that scenario. > Again though, the policy for onnv-gate was to never grow a second head - > so the strictly linear nature means +1 should never be unambiguous.
Only by chance. It's entirely possible for the changeset adding the tag to be far after the changeset it tags (unlikely in our case, but I could see situations where it maybe +2 or even +3). -- Rich
