Re: history

[Rudolph P. <r.p...@is...>]

On Sun, Sep 21, 2003 at 08:03:58PM +0100, Will Partain wrote:
> (I am still wondering about the "nice to have" vs the "no
> possible way can I do something cool without it" question
> :-)
I certainly think I could do some cool things with ark, but I want more
:)
> 
> One way to think about the "little .xml files with
> <prototypes>" in them: ARK semantics say you should be able
> to "pre-process" away the prototypes.  That is, you could
> expand the <prototypes> and then hang onto the expanded
> stuff in another .xml file and then just use that.
> 
> 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 ...")
> 
> Even then, though, the situation is far from perfect.  In
> the code for some method (now expanded out), you might make
> mention of '/our/bin/gcc'.  Well, six months ago, that meant
> GCC 3.1, but now it means GCC 3.3.1.  You haven't captured
> that change.
That seems like a hidden dependency more than anything
> 
> Even if you get around that one, there are still similar
> problems for the truly paranoid.  Every time you apply a
> patch bundle from Sun (say), it may change how
> /usr/bin/touch or /bin/ls works (well, *maybe*...) or
> [perhaps more significantly] some library API will wobble at
> the edges.  And your expanded-ARK-objects stuff will miss it
> entirely, unless you take extra measures.
Agreed, but that's another dependency thing.
> 
> The business of recording what-a-method-did along with its
> specification (i.e. code) is different from usual object
> thinking; but nothing inherently wrong with it.  I
> personally don't have a problem that the source
> (specification) is in one directory and the
> what-happened-when-I-ran-it info is in another.  Each one
> can be managed with as much or little care as you like.
> 
> But, hey, this is a *dev*elopment list... give us a use case
> or two, and we might even help :-)
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.
Hopefully that makes it more clear.

thanks