VCS thoughts

Some fast, probably cryptic, thoughts after a day merging with a "I wasn't familiar with it originally but I am painfully familiar with it now" VCS tool.

•  Merges are branches.
• Mercurial tracks merge workflow in a workspace, assuming that a merge will be a single commit.
• But today I had a complicated enough merge that I started a named branch off just for it. Accomplished the merge between my tasj branch and the trunk. And then merged back from this "merge branch" to the trunk.
• Worked fine, but it would have been nice to have some workflow tracking along the branch. Like "hg resolve", but "hg resolve" stops at the first commit boundary.
• Had to fall back to tracking things by hand, in a text file.

• Mercurial 's names are awkard
• "hg revert" isn't revert
• "hg revert -r REV file" isn't "revert".  It is "include this revision of the file in the candidate commit that you are building in your workspace.
• hg revert corresponds to cvs update
• "hg update" isn't update
• "hg update -r REVorBRABCH" isn't "update". It is "switch the revision or branch that the candidate commit you are building ijn the workspace will be applied to as a child."
• hg update corresponds to cvs checkout, although cvs is pretty sucky there too.  
• It's rather like a rebase when you have no revisions checked in yet
• Mercurial's branchs are not branches.
• They are floating tags
• Not necessarily lines of evolution.
• What would be a better name? "Stream of development?" "Genealogy line"?
• I'd like to have evolutionary branch0lines, as well as what Mercurial has.

• Tags should be versioned. 
• At least Mercurial got that right.
• But old tag versions should be visible in the log.
• And it should be possible to refer to an old tag version, something like "last week's official release"

• Mercurial's anonymous branches rule
• See, I am not purely dissing hg
• But "hg tip" has obviously not been brought up0 to date with named branches

• Can anyone tell me how to do the equivalent of "cvs update -j branch-base -j branch" in Mercurial?
• Without using an external patch
• Hint: "hg merge -r branch" doesn't work, if you have anti-patches on the branch

• I want to be able to "pull onto a branch" or "push a branch".  Not just "push or pull all the branches in the repository".  I.e. I want branch renaming or mapping in pull and push

• Mercurial doesn't do partial checkouts or checkins?
• Maybe not everywhere
• But you can screw yourself up in the same way with "hg ci incomplete list of files"
• I'm not suggesrting denying hg ci files partial
• But I'd like to do it in general.
• 
  
• Partial checkins and checjkourts should correspond to brancges, with merging actively encouraged.
• I've talked about this many times.

Enough already.

"system/command" versus "system command"

A lot of tools have a master command with subcommands. For example

hg clone ...
hg merge

cvs co
cvs update

git clomne
...

I think that the first place I encountered this was with mh. Or, since my friend MH says that mh did not have subcommands, I may have made the following change myself for mh. Why subcommands? I think mainly to avoid name collisions in the bin. Years ago, I kluged - I think it may have been the shell, whoever processes PATH - to search not just for "executable" on the PATH, but also "dir/executable". I.e. instead of saying

hg update

I colud have said

hg/update

Not much of a difference. But it makes it easier for guys to code systems that have lots of subcommands. Also, for users of shells like bash and csh: !hg/update works, whereas "!hg update" doesn't (unless your shell has tweaks.