links for 2009-07-01
-
"Remember that getting from each of step to the next in this sequence took a long time, both because it took time to realise that there was a problem in the first place, and because the respective right solution was not clear from foresight – trivially obvious as it may all seem when you see it laid out like here."
Last Day
Today is my last day of work at Stanford. Even though I’ll be here until August, tomorrow is the first day of my postdoc. It’s a bit of a weird feeling.
Tags: gradlifelinks for 2009-06-26
-
"Mine was a comfortable and happy childhood, and I spent much of it in the devoted service of the Great Old Pumpkin."
-
I'm going to call you Speak, because that's what you do.
links for 2009-06-20
-
"This will get you started using Mercurial, and you can adopt DVCS techniques slowly, as you need them." Ned writes up a tutorial so nobody else has to…
The best quotation for talking about multiple lines of development in a distributed version control repository
Young Doc: All you have to do is drive the time vehicle directly toward that screen accelerating to 88 miles an hour.
Marty McFly: Wait a minute, Doc. If I drive straight towards the screen, I’m gonna crash into those Indians.
Young Doc: Marty, you’re not thinking fourth dimensionally. You’ll instantly be transported back into 1885, and those Indians won’t even be there.
links for 2009-06-19
-
"hgview is a very helpful tool for daily work using the excellent DVCS Mercurial (which we heavily use at Logilab). It allows to easily and visually navigate your hg repository revision graphlog. It is written in Python and pyqt.
This version is an almost complete rewrite of hgview 0.x which had two GUI backends, gtk and qt4. This 1.0 release drops the gtk backend (we may consider reintroducing it, we haven't decided yet… by the way, patches are always welcome). Some may not like this choice, but the immediate benefit of using qt4 is that hgview works like a charm on MacOS X systems."
Mercurial again
I’ve got a longer post about my experiences with Mercurial last week, where we had a bunch of people committing, but I wanted to share that tonight I think I have turned a bit of a corner in understanding what it does and how to use it. I’ve been using “hgpullsvn” to keep the trunk in sync with my hg repo for yt, but tonight I imported the yt-1.5 branch, applied it as a separate branch, and then started merging individual changesets across them.
The unified-yt repo now has the full SVN history from the trunk as well as from the yt-1.5 branch, each of which lives in its own branch. On top of this I’ve placed the ‘yt’ branch (which is the trunk active-development) and the ’stable’ branch (which is yt-1.5, but with more rapid development.) I can generate diffs for patching the proper subversion trunk by updating and diffing:
$ hg up -C stable
$ hg diff -b -r yt-1.5 > my_patch
these can then be fed into patch, applied to the subversion tree and then committed. I have not fully thought through or tested the mechanism for backporting changes across branches simultaneously, but I think the transplant extension works nicely so far:
$ hg up -C stable
$ hg transplant -b yt-1.5
I think the “–filter” option can be used to get rid of the [svn ...] prefix of the header, but I’m not sure yet and I think it’ll require a bit more thought.
Anyway, I am digging hg, and I think I finally understand it and how it works and why multiple heads might be a good thing and how I can use it more efficiently.
Tags: code, Geeky, hg, mercuriallinks for 2009-06-12
links for 2009-06-11
-
de-mangling C++ names
-
Automatically generate a backtrace inside constructor of a C++ exception