Re: history

[Will P. <pa...@dc...>]

Rudolph Pereira wrote:

> > And since doing the prototypes expansion is a lot like doing
> > C pre-processing, you might as well accumulate the
> > dependency info ("foo.xml depends on prototype
> > "bar/baz.xml") and set up a makefile using it.  That could
> > be used to keep all of your expanded "objects" up-to-date.
>
> I'm not really following you, but that's mostly because I don't
> understand how I can apply the above to the history problem I am
> wrangling with (i.e, I would like to say "ah, so the <code> bit,
> configure options, etc for rsync-x.xx changed three weeks ago ...")

(sorry to be slow)

Well, here's a way (slightly beyond existing ARK code).
Imagine that ~/ark is where you keep your personal
checked-out copy of ARK teams' code -- exactly as now.

Similarly, /sys/ark/ might be a check-out of the Blessed
Version (what production hosts are playing to).  A human
being presumably decides that tagged version REL4_1 is now
production...

Now something new: /sys/myteam-ark-expanded/ would be the
/sys/ark/myteam objects expanded out with their prototypes.
This could be automated, once a day perhaps.  You could also
check them into CVS once a day as well.

You've now got a daily history of every object's fields.  It
would not be absolute rocket science to tag each field with
the date when it was last tampered with.

> As I hinted previously: say I changed the dependencies of
> the host object for host blah right now. Host blah is
> still, in fact, using it's old definition, at least until
> such time as it went and updated itself (remember, I'm not
> using push here).  I would like to record that fact
> somewhere (a status field would be ideal) and also record
> a timestamp (outside the client, i.e somewhere someone
> else would be able to get to it without logging on to the
> client) when host blah updated itself (e.g ran some
> methods, etc). The latter information sounds like it
> should be in some history-type area somehow associated
> with the blah host object.

What I have as the /d/ark-state area (NFS-available to
everyone), previously mentioned, is a lot like that.  A file
/d/ark-state/<object-type>/<object-name>/<method-name>--<who-for>.xml
[e.g. /d/ark-state/package/openssh--3.7.1p2/reveal--slicker.xml]
means that who-for (or a proxy for it) ran method-name of
object-name at <the timestamp of the file>.  Other details
are in the .xml file.

It would certainly not be hard to find out things like "the
code for that method has changed since you ran it".  I'm far
from convinced that you then ought to re-run it.  I lean to
the view that a little entropy in the system is no bad thing
:-) -- but others (e.g. Joel S) thankfully take a different
view.

Are we getting anywhere useful to you?

Will