Some things I don't Understand

bradford fingermark at gmail.com
Tue Feb 24 08:34:57 CST 2009


Thanks for your answer Giorgos.  Most of the mercurial tips and
workflows I have "delicioused" are ML comments that you have made
(available via nabble).

It may be that I am still learning mercurial, but I do not understand
the point of this:

 hg up -C keramida-test
 hg merge d707a0286621
 hg commit -m 'Merge from upstream'

Is d707a0286621 the tip (and the 'keramida' bookmark)?  Won't the
changes be merged in when you hg pull, hg update, and hg merge?  Why
would you need to update to your older revision?

If you did
 hg up -C keramida-test
 ** change some code **
 hg merge d707a0286621
 hg commit -m 'Merge from upstream'

Then I could understand this.

Thanks again,
Bradford

>> 1) How else can bookmarks be used other than to just give revisions a
>> memorable name?
>
> I use them to create `sliding tags' in the trees where I locally track
> upstream sources.  With the following option in my `.hgrc' file:
>
>  [bookmarks]
>  track.current = True
>
> I can create local tag-like names for a changeset, i.e. by typing:
>
>  hg bookmark -r 3f478ae4290b keramida-test
>
> If I commit a few local changes, I can 'slide' the tag with:
>
>  hg bookmark -f -r b301f69d064a keramida-test
>
> Then a few days later, when I pull from an upstream repository and want
> to merge with my local changes, I can use:
>
>  hg up -C keramida-test
>  hg merge d707a0286621
>  hg commit -m 'Merge from upstream'
>
> The `keramida' tag slides automatically forward, so I can keep using it
> as a quick name for the most recent changeset I am probably interested
> to work with.
>
> Another use of bookmarks is to create quick local tags for changes, and
> be able to delete them without having to actually *save* the tag name in
> the history of the repository for ever.  This may be a very handy
> feature if you are trying to work on a feature *before* the release
> management person or team has actually decided on a name for the tag.
>
> When the name is decided, you can go back and replace the bookmark with
> a "real" tag.
>
>> 2) I find myself always cloning repositories when I work on a feature.
>> This is fine, but I'm wondering if I'm missing out on something.  Am I?
>
> Maybe.  But then again, maybe not.  Cloning is the `safe and easy' way
> to do branches for me.  It is clean, easy to do, and its semantics are
> very easy to understand:
>
>  * Create a clone.
>  * Commit a few changes to the clone.
>  * (OPTIONAL) If you haven't pushed yet, reorder and edit history to
>    match the style you want it to use when public.
>  * Push the changes to the parent repository of the clone.
>
> That's all.  I like being able to describe in 3 easy steps (or 4 if you
> like history editing).  It makes people less scared of using an SCM
> system, and that is good :)
>
> I'll let others answer the rest of the questions.  I am not using the
> local branch extension or hgsubversion.
>
> HTH,
> Giorgos
>
>



More information about the Mercurial mailing list