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

[Samium Gromoff]

At Fri, 12 Dec 2003 19:10:54 +0100,
David Allouche wrote:
> 
> 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

As somebody who gets to parse tla`s output i wholeheartedly support your
resistance to uglification of supposedly machine-parsable data.

And after all, afaics tla is not supposed to be used as a user interface
in future -- itla or etla is.

> 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.

regards, Samium Gromoff