Re: [Gnu-arch-users] Re: Changelog and branches

[David Allouche]

On Fri, Dec 12, 2003 at 02:45:48PM +0000, Stig Brautaset wrote:
> On Dec 12 2003, Edouard wrote:
> > As  changelog is  only supposed  to be  a human  representation  of arch
> > maintained history,  would it  not be better  to simplify its  output in
> > such a case ?
> ...
> > It  could  be   turned  into  something  looking  a   bit  like  abrowse
> > archive/category output:
> >  new patches:
> >     address@hidden/xvidcore--devapi4--1.0
> >       base-0 .. patch-80
> 
> 
> Sounds great :)

Sounds like something dangerous.

I do not think that changelogs are only supposed to be human-readable
representation. They can be used by automated tools for a lot of
purposes:

  -- addition of specific headers

  -- fast access to changeset information

That last point is the sticky one. Of course, a patchlog does not aim at
being a full representation of its original changeset, but often it
contain the exact information you need, and it is an order of magnitude
cheaper to work on a patchlog than on a full changesets.

For example the "file-history" feature _can_ be implemented by parsing
renames from the patchlogs, computing the ancestry from patchlogs, and
only expanding changesets which actually make changes to the considered
file.

At the moment, the patchlogs are not really parsed by any widely used
automated tool, but that is something which is likely to change because
they allow to implement efficient solutions to some otherwise bothersome
problems.

The bottom line is: patchlogs are for machine as well as for human
consumption. Changes to the patchlog format should be carefully
considered by keeping both uses in mind.

In this particular case, it is not overly difficult to parse the
modified syntax. But an extra option to the various cat-*log commands
could enable this bit of beautification, or that could be made the
default, as long as there is an option to retrieve the raw patchlog.
This would provide the desired convenience, except for non-arch users
who dig in archives by hand, without losing any programmatic
convenience.

-- 
                                                            -- ddaa

David Allouche         | GNU TeXmacs -- Writing is a pleasure
Free software engineer |    http://www.texmacs.org
   http://ddaa.net     |    http://savannah.gnu.org/projects/texmacs
   address@hidden  |    address@hidden
TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.