Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Wednesday, January 18, 2012

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.