attributes on closing tag (pseudo-XML)

Here's an example of why I like having the ability to place attributes on closing tags in pseudo-XML.  Proper XML only allow attributes on opening tags.

I like using pseudo-XML to structure the output of a test suite. For example:

<test start "foo" >
<test start "bar">
<test "1" passed>
...
</test end "bar" passed=10 failed=0>
<test start "baz">
...
</test end "baz" passed=13 failed=2>
</test end "foo" passed=13 failed=2>

More nicely indented:
<test start "foo" >
    <test start "bar">
        <test "1" passed>
        ...
    </test end "bar" passed=10 failed=0>
    <test start "baz">
    ...
    </test end "baz" passed=13 failed=2>
</test end "foo" passed=13 failed=2>

Anyway, the basic idea is to use pseudo XML ...s to encapsulate test output.

When I translate from pseudo XML to real XML, I can use any of several nice viewers that allow sections to be opened and closed.  E.g. Internet Explorer.

Placing attributes on the closing tag allows me to do such processing in a single pass.  E.g. in a UNIX pipeline:

run-test-suite | collate-results

This is one of the reasons I like being able to place attributes on closing tags: it allows single pass processing.  Often, I am processing some other program's output.

I am fine on eventually converting to standard XML. If necedssary.

---

By the way, I do pseudo-XML, like

<test "name" passed assertions=56>

mainly because I find it more human readable than


<test name=-"name" passed="true" assertions="56">

Human readability counts, since there is not such a plethora of XML tools on the UNIX command line that I never look at the raw text.

ISO composite workspaces

Here's the thing that I really miss in the Mercurial based version control I am currently using; i.e. here is something that CVS used to do really well, that Mercurial makes a pain.

Composite workspaces.

Here's the output of a shell scruipt that goes and looks at 4 of the hg repos/clone/workspaces that I am normally working in:

/home/glew/.
        hg root: /home/glew
/home/glew/mips/.
        hg root: /home/glew/work/work.mips
M LOG
M tools/ag-mips-automation/ag-mips-automation.pl
/home/glew/mips/uarch-perf-sim/psim+stuff/.
        hg root: /home/glew/work/work.mips/uarch-perf-sim/psim+stuff
M psim-extra-stuff/diag_instruction_list_including_undefined_instructions.s
M psim-extra-stuff/parse-rtl.trace-or-ref.trace
/home/glew/mips/rtl/.
        hg root: /home/imp_scratch_perf/glew

It's not too bad - I've only made coordinated changes in two repos.  Sometimes I have made changes in 4 or 5, that are all coordinated in some sense.

Back in my CVS days I could build a composite workspace, and check them all in at the same time, with a single command and checkin message. I could even tag them together.

In Mercurial, I have to go to each repo and check in separately.

Don't say "subrepos": I am already using Mercurial subrepos: psim+stuff is actually a super-repo with 2 subrepos.  Subrepos get part of the way there, but are nowhere as easy and convenient to use as the compositeworkspaces I could set up with CVS.

---

I am reasonably certain that the above excerpt is non sensitive: it's pretty well known that I work for MIPS, on performance simulators, and with RTL.  I sanitized any product names.

---

One big reason to want composite checkins: I work better when I am keeping track in a log.  E.g. ~/LOG -> ~/mips/LOG.

(Let's skip over issues about why UNIX text files are lousy for logs.)

So nearly always I want to check in both my LOG, and my project work, at the same time.  But they are in different repos.

---

I don't make my project work a subrepo of my home directory, ~, or of my company work area under my home directory, ~/work or ~/work/work.mips, because I frequently create new ad-hoc clones, i.e. task branches.  It is a pain to have to edit Mercurial's subrepo file whenever I want an ad-hoc branch.

The nice thing about CVS composite workspaces was that, in some existing workspace, I could just say "cvs -d SOME-OTHER-CVSROOT co repo"  and it just worked.  I.e. connecting an ad hoc subrepo trivial.

In an ideal world, I might want to make the distinction

(1) clone into a new subdirectory of an existing workspace, implicitly making it an ad hoc subrepo for the workspace checking out into

(2) clone, without linking into the enclosing workspace.

---


Almost what I want:

#!/bin/sh



# Script to run Mercurial commands on tghe usual places I run them



for i in  ~/. ~/mips/. ~/mips/uarch-perf-sim/psim+stuff/. ~/mips/rtl/. ~/mips/rtl/current/.

do

 echo $i

 hg --cwd $i root 2>&1 | sed -e 's/^/        hg root: /'

 hg --cwd $i "$@" 2>&1 | sed -e 's/^/        /'

done

although "hgu ci" does not automatically copy checkin message between repos.