links for 2009-07-03

No tag for this post.

links for 2009-07-01

No tag for this post.

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: gradlife

links for 2009-06-26

No tag for this post.

links for 2009-06-20

No tag for this post.

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.

Tags: hg, mercurial, versioncontrol

links for 2009-06-19

  • (tags: mercurial hg)
  • "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."

Tags: python

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, mercurial

links for 2009-06-12

Tags: code, python

links for 2009-06-11

No tag for this post.

Next Page »