#TORTOISEHG TAG VS BOOKMARK FREE#

That ensures that these important branches and tags look the same to everyone.Īgain, I've no idea whether this is how one's supposed to use mercurial, but it seems to be a model that works well for our size of team. You can use multiple bookmarks to keep track of progress.

Our released major versions all have their own named branches off from the main line, and minor versions have tags on those branches. As you move from page to page, you move the bookmark forward with you. I myself almost never make non-local tags or named branches (except by accident, and I destroy them if I do). They make interesting past states easier to find. I use local tags to mark revisions I might like to come back to one day. If I feel my memory slipping about a twig that's been around for a bit, I bookmark it. But several people are a bit scared of it and prefer if I send them diffs that they can apply with patch.įor experiments I expect to be short lived and private, I just let lightweight branches happen where they may, and remember what's going on. I'll occasionally push some changesets to a co-worker if they're one of the people who's comfy with how mercurial works. Occasionally once an experiment has worked out I'll modify the main line and push a changeset into the central repository, from which it will find its way to everyone else's machine. I make many experiments and lightweight branches in my own private repository, which never get pushed to our main central repository. I'm working on a single shared repository with about 20 other people. How I actually use these things in practice.

#TORTOISEHG TAG VS BOOKMARK FREE#

If anyone knows better than me then feel free to edit this answer so it's correct.

After about twelve months of using mercurial daily I haven't really got to grips with its model(s). They tend to be local to your repository, and won't propagate unless you propagate them deliberately.Īt least I think that's how they all work. So they're not represented as part of the repository history. They're metadata rather than being mixed in with the versioned objects. Local tags and bookmarks are much more like what git calls tags and branches. They'll tend to propagate to other repositories in ways which are not necessarily obvious. Named branches and tags are mercurial-only concepts where the branch names and tags actually get recorded in the repository by making more commits to the repository. The other four are ways of annotating lightweight branches and the changesets that make them up. Your repository history forks and sometimes merges as you change things and move around your history. Lightweight branches are what happens if you just use mercurial. That is even more confusing that teaching people that default means 'the normal branch where you should work by default'.There are actually five concepts to play with: So if you have a dev and prod branch in the repo, then a new clone will checkout a 'random' changeset depending on where the last commit was made. This is a bad idea since this changeset changes every time something is pushed to the repository. When there is no default branch present, hg clone will checkout the tip-most changeset. This can be done by not creating one in the first place: $ hg init repo People sometimes try to delete the default branch. You should always make default the branch the branch that users want to checkout. You cannot make another branch the default branch, by which I mean you cannot tell Mercurial that you would like branch-X to be checked out in a new clone. Your users will have to be careful about keeping the bookmark pointed at the branch head they want, though.

This answer has become outdated: you can now add a bookmark and Mercurial 2.4 and later will automatically check it out for a new clone.

Tortoisehg tag vs bookmark