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.

Tuesday, April 24, 2012

status files to work around version control limitations (esp. in hg)

---+ Recent status

Tue Apr 24 10:59:29 2012: XXX branch

Andy Glew creating the hg branch "XXX", for, duh, XXX related work.  I
want to push this branch to the main repository, but not merge it with
the default trunk - if for no other reason than that is a way of
getting other team members to see my code, possibly make comments, and
tell me how stupid I am.

But I don't want to place in mainline, because it is not ready.

I will try to keep these branch checkins clean.  I.e. I will edit
history to collapse some stupid checkins.  Although probably not so
much as if pushing directly to the mainline.

I am using this "status.txt" file to record branching arrangement, as
described below.

But also to work around an HG limitation: hg has an important default
label "tip", which many tools think is the tip of the main default
trunk. If you push a branch, and tip gets set to the branch, many
things break.  The only way I have found so far to avoid this is to
make a change to the trunk when pushing my branch.  This status.txt
file is a way of accomplishing that.

---+ What this is: Status files like status.txt

This file is to record status.

Why can't status be seen in the version control logs?  Well, it can,

---++ Post-checkin status determination


You make changes.  Test Check in.  Write a log message.

So far so good.

But then you realize that something broke.  But you don't have time to
fix it right away.

If you could do a dummy checkin, with nothing except status, that
would be okay.

CVS supports this:

    cvs commit
        This option is present in CVS 1.3-s3 and later releases of
CVS. Note that this is not the standard meaning of the -f
option as defined in Common options.  Force CVS to commit a
new revision even if you haven't made any changes to the
file. If the current revision of file is 1.7, then the
following two commands are equivalent:

$ cvs commit -f file
$ cvs commit -r 1.8 file

As far as I can tell, Mercurial does not.

So I therefore add this file, status.txt.  Typically I will place a
status message, like "Tests not originally run fail" in this file, and
in the commit log.  Nice to date them

---++ Branch Status

I have used this approach also for branch status.  Sure, branch status
may be in the version control log (modulo the limitations of hg
above).  But somebody working on the main line may filter out branch
status and log messages.

Therefore, I will sometimes record branch status on a file like
status.txt (or branch-status.txt, or repo-status.txt) that I kep on
the trunk.  Stuff like "I am working on the XXX, and I fixed the
foobar bug, but I am not ready to put it on the trunk, so check out

I.e. I sometimes use VCS to track work-in-progress, not just history.
(If that WIP takwes a while, it is both WIP and history.)

It would be nice if something like branch-status could be seen on all
branches.  Or, perhaps, consider it as a subrepo shared between
multiple branches, separate frolm the rest of the repo.  But that's

No comments: