co -r REV workspace = overlay co -r REV source + co -r LATEST metadata?

The Mercurial way seems to be to handle files and only files.

Metadata, like svn proprerties, indicating whether tests habve passed or not, in the Mercurial mindset lives only in files.  See, for example:

http://stackoverflow.com/questions/4443712/is-there-a-mercurial-extension-like-svn-propset

I actually am okay by this. Keep stuff in files.  However, I think there are issues wrt how a workspace should be assembled: more and more I think of a workspace as an overlay of metadata, in files, that transcends versions, and the actual versioned source code files.

I.e. if you have a file that describes all of the branches in a repo, and what they are used for, it rather defeats the purpose if, when you update the workspace to a branch, you lose other

Bob Colwell / Craig Barrett

http://newsletter.sigmicro.org/sigmicro-oral-history-transcripts/Bob-Colwell-Transcript.pdf


0:27:22 BC: That never happened. Instead, for example five Intel fellows including me went to visit Craig Barrett in June of 98 with the same Itanium story, that Itanium was not going to be able to deliver what was being promised. The positioning of Itanium relative to the x86
line  is wrong, because x86 is going to better than you think and Itanium is going to be worse and they're going to meet in the middle. We're being forced to put a gap in the product lines between Itanium and x86 to try to boost the prospects for Itanium. There's a gap there now that AMD is going to drive a truck through, they're going to, what do you think they're going to hit, they're going to go right after that hole" which in fact they did. It didn't take any deep insight to see all of these things, but Craig essentially got really mad at us, kicked us out of his office and said (and this is a direct quote) "I don't pay you to bring me bad news, I pay you to go make my plans work out".

0:28:26 BC: So and he, and at that point he stood up and walked out and to back of his head. I said, "Well that's just great Craig. You ignored the message and shot the messengers. I'll never be back no matter how strong of a message I've got that you need to hear, I'll never bring it to you now.”

small files may be their own checkin log message

sometimes I find myself taking the contents of a small file that I am checking in, e.g. with hg ci,
and inserting the contents of that file as the checkin log mesage.

I.e. sometimes the file itself explains what it is better than words can.

Typical for small scripts, on or two liners.

This makes some history messages that interleave log message and file contents ugly.

Note: often not the entire checking log.  Often I put a little bit of text explaining.

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.