Posts Tagged ‘mercurial

01
Dec
09

Switcher

So after trying to flex Git to use a huge software base, I’ve moved to Mercurial and am finding it really wonderful.

First off, windows integration is especially beautiful. You don’t need an extra shell, you don’t need Cygwin, you don’t need OpenSSH. It’s just a great experience in Windows. I’m also using TortoiseHg. TortoiseHg seems to be a better experience than TortoiseGit and they’ve paid closer attention to the collective dismissal of windows on pressing OK, an annoyance to me with TG.

Furthermore, UTF-16 files seem to be supported out of the box (probably because Hg’s written in Python). A project that I frustratingly tried to commit to a Git repo was a breeze with Mercurial due to the UTF-16 support. The way that Visual Studio saves files, you can’t be certain that UTF-16 won’t be the file format, but that is a non-issue for Mercurial, which eats ’em up with out a blink.

Lastly, support for massive code bases is a big win at my company where our source repo is upwards of multiple Gigs. Git’s premise that the Linux Kernel source is “huge” is utterly laughable. Mercurial swallowed up our code quickly and didn’t have any issues diffing changes and I didn’t have to go figure out creating sub-repositories to get better performance. This singular feature is HUGE to me.

Advertisements
17
Nov
09

Git Submodules

I have been wanting to learn more about Git Submodules and how they work, so I watched the screen cast at the bottom of http://book.git-scm.com/5_submodules.html (would have embedded it, but there were issues doing so). The bottom line is that the Super module contains a reference to a specific version of a Sub module. Git’s submodule command can then determine if you have a different version of the Sub than you should, it can fetch the current version, etc.

The process sort of goes like this, using C1 for Computer 1 and C2 for Computer 2:

  1. C1: change Submodule
  2. C1: commit Super module, freezing version of Sub used by Super
  3. C1: push Super module
  4. C2: pull Super module, gets the updated Sub module version SHA
  5. C2: submodule update, gets the updated Sub code corresponding to the version in #4.

Some observations:

  • Will a user ever do 4 and NOT do 5? Why?
  • If 4 and 5 are tied together, why is that not one step (ala git push = git fetch; git merge origin/master)?
  • C2 has no idea to update the Sub code unless they are carefully watching the pull output or run git submodule status directly after 4 above to know that a Sub update is needed
  • Possible source of issues if C2 has Version x+1 of Super but only version x of Sub

Now, I’m new to Git, but it would seem to me that one could write a hook that would automatically run git submodule update if .gitmodules is present in the directory. It would seem that an appropriate hook to git pull would be to add git submodule update after the pull. Am I missing something here?

I understand that git’s submodule support has been added-on as submodules were not something in the design of Git. I wonder if the lack of these hooks and a better user experience is the direct side effect of that bolt-on?

Mercurial seems to be trying to do this via it’s subrepos support:

Whenever newer Mercurial versions encounter this .hgsubstate file when updating your working directory, they’ll attempt to pull the specified subrepos and update them to the appropriate state.

Enough to make me switch? Not if I can write a hook.




Twitter Updates