Mercurial is also distributed, but it's very, very fast. It's even (gasp) well-documented! There are, however, a few things I think a newbie should know up-front.
- The tutorial assumes you'll start by copying an existing mercurial repository. I wanted my own, though, and it took me several tries to figure out that I needed to do this:
~/existing$ hg init
~/existing$ hg add foo.bar
~/existing$ hg commit
~/existing$ cd ..
~$ hg clone existing newdir
Later on, if I make new files inexisting
, they won't get tonewdir
until I~/existing$ hg add newfoo.bar
~/existing$ hg commit
~/existing$ cd ../newdir
~/newdir$ hg pull
~/newdir$ hg updatepull
brings fresh metadata in from the other repository, storing it in .hg, but doesn't actually go on to update the files themselves. That's whatupdate
does. It took a while to get it, but now that I do, it seems intuitive and helps me feel in control. - Your EDITOR or HGEDITOR environment variable must be set, or else
hg commit
will hurl you pitilessly into vi (*nix) or throw up its hands and scoff at you (Windows). - But, if you use gedit and already have another file open in it, you get
~/existing$ hg commit
transaction abort!
rollback completed
I suspect that may happen with other multi-file editors, too. I'll useEXPORT HGEDITOR=pico
.
2 comments:
Just curious if you’ve tried moving a repository. I’m using version 0.9.3+20061222 on a “Billy Box” and have had no luck. I agree that the docs are great, but they’re a tease right now, in a sadistic kind of way, when it comes to “rename”.
The repository lives in the .hg subdirectory of the current working directory.
I just found out that when you have named branches, hg clone will create a new working directory on the "default" branch, and not the tip.
The "Update" command is quite unlike the Update in svn. It is used as a "GOTO" revision number. If you
hg update -C -r 5
and you commit some changes, you've created a branch of your repository back at that point in time.
ie.
4----5----6-----7
|
+--->8
Post a Comment