Partial checkins, file objects not necessary

I very much want partial checkins and checkouts in my version control systems.  I had them in SVN and CVS.  I lost them with DVCS.

I have posted elsewhere about DVCS compatible concepts that might support partial checkins and checkouts.

Partial checkouts are not that hard to imagine.  E.g. to checkout a subdirectory tree, scan the repo for all history relating to files that ever were in that subdirectory.
     Use whatever "history relating to" criteria you want: was in a file in that subdirectory, was in a file that at some point in its history was ever moved under that subdirectory.  Possibly the hypothetical git-like "looks like a piece of code that once lived in a file under that subdirectory". Just not "true always".
     One might provide the full history of all such files in the partial checkout or clone, although it might not be possible to checkout some files from the partial clone repo history into the partial clone workspace, since to be properly checked out some versions might lie outside the cloned subdirectory.  But one could at least access from the history.
     Some fun in ensuring that one can check out into the workspace different versions that lived at different places in the overall directory tree - i.e. where the whole subtree was moved.

Partial checkins are a bit more of a problem, given the desire for atomicity and conistency: one wants to at least give a chance to ensure that an entire repo is consistent, can pass all tests. Automatically including a partial checkin in the default trunk of the enclosing project would break this.
     The basic idea is for partial checkins to automatically create branches.  And then for the superrepository to be strongly encouraged to merge such partial checkin branches into the default trunk (or whatever branch was partially checked out from).  Somewhat like the way Mercurial automatically creates heads, anonymous branches, when there were conflicting edits to the same branch.  Now one would have heads, but not all heads would imnclude the entire repo, some might be for partial checkins.

 I have long been troubled, however, is that the easiest way to imagine building this is to create history objects that correspond to files.  A project version would be a mapping of pathnames within the repo to a set of history objects. A project might be defined to want to include the latest version of any particular history object going forward, but not to actually include it until the user has had a chance to test all together.

This troubles me because, while I think Linus is excessively pedantic for forbidding rename tracking in git, I agree with him that file rename tracking is primitive. I really do want to track functions as they are cut and pasted between files.
     I have long been fascinated by bits and rumours I have heard about non file based version control systems.  E.g. old systems that were conceptual card decks - where you didn't lock a file, but you checked out and in ranges of cards, potentially replacing a range with a larger or smaller number of cards.  Or with IBM Visual Age for Smalltalk/Java/C++, which seems not to be inherently file granularity.

History objects corresponding to files get in the way of this.

I think now I can see how to generalize this.  I often imagine a filesystem as an XML database - the hierarchy is natural. The old "version control of card decks" applies. One can imagine the patches for any subtree being under that subtree in the XML.
     OK, XML is horrible.  But it just shows the direction. Not "patch objects" that apply to the while monolithic project, but patches that are themselves an interlaved collection of patches to files and subdirs.  With the ability to interleave and uninterleave patches according to filesystems.

Dataflow scheduling for ordinary software - providing error messages as early as possible

I just ran a rather slow tool that ran for a long time to produce an error message that it could have figured out immediately.

Oh, heck, I might as well say what it was:

I just typed in

hg revert -r default

instead of

hg revert -r default .hgrc

Mercurial went and scanned my home directory repository, which is rather large, taking 10+ minutes to scan, before it gave me the error message

abort: no files or directories specified

It would have been nice if it had reported the error message immediately, instead of scanning the repo.

This isn't just Mercurial specific: other tools have the same problem.  Some of them my tools.

It is nice if interactive tools report error messages as soon as possible.

Aspect oriented program might help.  Create an aspect for "command line checking", and reorder code that is related to command line checking earlier.

Dataflow analysis might also help.  In an ideal world, sans ambiguous points, etc., it would be evident that the error check depended only on the command line, and could be moved up earlier.

--

This is just part of my not-so-hidden agenda, to apply dataflow everywhere.

Trackers

I am getting into trackers, as in Quantified Self.

But the tracking apps that you have to invoke manually are too high overhead.

I used to use a chess clock to track time working versus lost to IT bugs.

Idea: extend and adapt this for multiple trackers.

E.g. start off with an Android chess clock like tracker.  Big buttons saying working, lunch, hung, ...

Extend to scroll through a list of tracker/samplers. 

Find latest version of tool on path

Frustrated by systems where there isn't a single order of bin directories that can arrange for the most recent version of tools to be used, I wrote a tool to find the latest version of a tool on the path:


~/bin/path-version -latest -verbose --version -print -exec bash -c 'echo hi from bash $($SHELL -version)'
/home/glew/bin/bash: 3.2.25(1)-release
/usr/local/bin/bash: 2.05a.0(2)-release
/bin/bash: 3.2.25(1)-release
latest: /home/glew/bin/bash: 3.2.25(1)-release
exec /home/glew/bin/bash, -c echo hi from bash $($SHELL -version);
hello /bin/bash -c echo hi from bash $($SHELL -version)
hi from bash GNU bash, version 3.2.25(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc.

--version (or -v, or -V, or -version) is the knob passed to the tool to query its version.

you can print all version, just the most recent, or just exec.

-- 

Based on a Perl library I just wrote, Version_Numbers.pm, that parses Version number strings of several syntaxes.  I.e. not just Perl's, and not just 1.2.3

I was surprised not to find such a library already existing.  Some were close, but not quite there.

Also compares.  Although the comparison rules are  a it two simplistic: strings are lexically sorted, whereas possibly

1.2rc should be less recent than 1.2, if the latter is what actually got released.

Capabilities created on the fly

I'm a fan of capabilities.

But a problem with capabilities systems is creating and maintaining the capabilities.

If somebody has to design the capabilitis, then you end up with a finite list for whatever the creator anticipated you might ask for.  Something like Android's app privileges: "This app requests full Internet access."

Hell, no: I only want it to access particular sites.  And I only want it to send data from certain files. ...

But what OS writer wants to code all of that up?

--

How about creating capabilities on the fly.

E.g. create capabilities automatically for all syscalls:

"open( function_or_regexp_to_be_applied_filename, function_to_be_applied_to_permissions)"

like

open
only files under such and such a directory
    owned by such and such a user
    after a scan has ben done on them
read-only


"* ... "

any syscall
with a filename argument that meets certain criteria ...
...



---

Since syscalls are rather low level, might apply this to any function call or library.

---

In general, want functions to be applied before the call, given the call, arguments.  Possibly caller...  (like "No socket opens from the user interaction facility".

Possibly evaluate on the raw call and args.
Better yet if can be evaluated on the canonicalized data that might be recorded in a log file - e.g. where filenames are made absolute, etc.

---

This doesn't eliminate the need to design coherent capabilties systems.

But it does mean that you can fairly create iron-clad invariants, such as only files in a particular place are accessed.

Aargh!! Out of date systems!!!

Aargh!!! I am sick and tired of working on out of date Linux boxes (that I am not sysadmin ion, that I cannot easily update.)

Today's trivial annoyance:

bash prompt \D{strftime format}

doesn't work on the bash 2.05a.0(2) copyright 2001
installed on the machine I am working on at work
works on a more recent ubuntu ...  4.1.5(1) - copyright 2009

---

Many pf my frioends just maintain their own virtual machines with whatever they depend on
- usually more recent than work - installed.
I must start doing that.

(Last time I tried, I ran out of disk space. Plus, the laptop I can install on is much slower than the workstations I can run on, even though they have old software.)

And then there's the risk that what works in my virtual box won't work on a standard work machine that somebody else is using...


--

These are trivial annoyances.  But finding failures like this wastes a trivial amount of time.  Many times in any given week.

Brackets - XML, and non

I like XML's "brackets":  <longname attributes="attributes"> ... </longname>.

Makes XML much less vulnerable to mismatches like dropping a paren:

<A> <B> <C> <D> ... </D> </B> </A> - the missing &lt/C> can be inferred, and possibly even repaired

(A: (B: (C: (D: .... ) ) )
which closing paren is missing? A, B, C, or D's?

But... sometimes I end up editing XML by hand. (Like on a wiki. (Or in blogger :-( )  And sometimes typing <longname>...</longname> is just too much.

Sometimes I would like the option of having a more compact, but less robust, bracket notation. Like the above mentioned (A: ... )

Or [A: ... ].  Or {B: ...}.  Or (although that latter is hard to tell from XML.)

Consider

<A> (B: {C: [D: ... ] ) </A>

it is still pretty easier to infer that the closing } for {C:  is missing.

Here's a thought: the matchingness of brackets is orthogonal to the actual name of the construct that uses the bracket - in XML parlance, the element.

LISP dialects that use only parens ( and ) exclusively are at one end of the spectrum.

XML, with arbitrary <tag> ... </tag> is at the other end.

And in between, we can have notations that use matching { and }, [ and ], < and >, << and >> - heck, Perl and regexps show that there don't even need to be matching pairs.  ' and '. " and ". Or ‘ and ’, etc.

These could be intermixed, as I have done before.

Indeed, the same entity, the same statement type, could use either bracketing form: &ltA> (A: ... ) </A>

I can imagine tools that translate between these forms.

From XML: &ltA> <A> ... </A> </A>

To strictly lisp-like parens: (A: (A: ... ) )

To forms that employ multiple bracket types for "clarity": (A: {A: ... } )

 ---

I guess that I am using (A: ...) as the compact representation of <A>...</A>.

Q: what about attributes? (A at1="at1" at2="at2" ... : ...)

 ---

There seems to be little lossage here. Except for the lost opportunity to place attributes on closing XML tags, <tag attributes>...</A closing-attributes> --- something that XML does not allow, but which I have supported in my own pseudo-XML dialects.