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.

Thursday, July 19, 2012

Repo state on branches

Interesting:

if you do hg clone -r default

(m)any branches that were closed will now be reopened.

Because the Mercurial close record for a branch is usually a stub in the revision tree.

This is suboptimal.

It is also the sort of thing I have been obsessing about, both for source code version control, but also for logs: some state may want to transcend branches.

Code phases: Distinction between simulation and instrumentation code

I often find in simulators that I want to distinguish the simulation code, the code actually needed to run, from the instrumentation code.  The latter exists only for analysis of the results, but is not necessary if all you care about is functional correctness.

Information should only flow one way, from simulation code to instrumentation. Never backwards.

I have experimented with C preprocessor macrios like  INSTRUMENTATION( perf_counter++ ), and so on, but these are clumsy.  I will admitt hat INSTRUMENTATION: looks better than INSTRUMENTATION( )

If you use sch macros, you can always do #define INSTRUMENTATION(x) /*nothing*/
and test that it still compiles and runs tests.

However, simulation/instrumentation are just two phases of code.

Debug may be a another phase, at least read-only debug observation. (Sometimes there is active debug, that influences the actual running.)

Asserts are yet another phase.  Different from debug, because you often leave them on.

In both debg and assert phases, information flows from program main phase to the phases.

How about server/client partitioning?  Although in this case data flows both ways.


== and !=

Q: should you always define operator!=() when operator==() is defined?

Uncomparables, where neither == or != are defined?   Essentially, true, false, unknown.

File by file merge

Screw this "treat the whole repository as a single thing".

To disentangle a thrash, I am copying files one or two at a ti,me from a thrashing branch to a new branch.

Something like

     hg update -r careful-branch
     hg revert -r thrashing-branch file1.cpp file1.h
     ...
     hg ci -m 'file1.cpp/.h merged from careful-branch'


Basically doing a file by file merge.

It sucks that Mercurial does not record this as a merge.  Doesn't show up in the graphical diagram drawn by glog.  I'd like some sort of dotted line.

Hmm : could track workflow - what files remain to be merged.   Even on a diff chunk by chunk basis:

merge this chunk ; reject this chunk; defer until next pass.