Re: [9fans] Changelogs & Patches?

[Roman Shaposhnik <rvs@sun.com>]

On Dec 26, 2008, at 5:27 AM, Charles Forsyth wrote:
>> while a descriptive history is good, it takes a lot of extra work
>> to generate.
>
> i've rarely found per-change histories to be any more useful than
> most other comments, i'm afraid.

I believe that it all depends on what is it that you look at source
code for. Long time ago I used
to study mathematics. Soviet mathematical schooling was really quite
exceptional, but there
was one thing that I now wish was different. You see, soviet math got
a Bourbaki virus in its
early childhood. And that meant that math texts and math teaching was
all about polished
final results. None of that messy and disgusting process of actually
discovering those results.
None. The process itself was considered too imprecise and muddy:
    "Rigor consisted in getting rid of an accretion of superfluous
details. Conversely, lack of rigor
     gave my father an impression of a proof where one was walking in
mud, where one had to pick
     up some sort of filth in order to get ahead. Once that filth was
taken away, one could get at the
     mathematical object, a sort of crystallized body whose essence is
its structure."
                                                               From: http://ega-math.ru/Cartier.htm
And thus the circle of those who "just got it" was formed.

Back when I was a student, I wanted to belong to that circle so badly,
that I missed a fundamental
point: the very creation of the circle turned all of us from active
participants in the process into
art gallery goers. And that was a fine change for those who just
wanted to appreciate fine
math, but was a kiss of death for less gifted individuals who wanted
to do math themselves (I won't
touch the subject of whether less gifted individuals are supposed to
do math in the first place, since
its too personal and painful).

Ok, with math it is a bit difficult to have the records of the process
AND the final object at the
same time (well, good teachers understood that and their lectures were
the ones worth attending).
But in software engineering we DO have a chance to have our cake and
eat it too. Albeit only
if we put as much focus on maintaining history (our records of the
process) as we put on
maintaing the code itself (final results).

> the advantage of dump and snap is that the scope is the whole
> system: including emails, discussion documents,
> the code, supporting tools -- everything in digital form.  if
> software works differently today
> compared to yesterday, then in most cases, i'd expect 9fs dump to
> make it easy to track down the
> set of differences, and narrow the search to the culprit. it might
> not even be a source change,
> but a configuration file, or a file was moved or removed.

I don't deny that 9fs dump is quite useful and it seems to match the
organization of Plan9 developer
club pretty well. Personally, though, I'd say that the usefulness of
the dump would be greatly improved
if one had an ability to do ad-hoc archival snapshots AND assigning
tags, not only dates to them.

That would, in effect, bring the whole process quite close to what
established SCMs do. With
the only major feature (the ability to easily trade history between
different hosts) still missing.

Thanks,
Roman.