Re: [Gnu-arch-users] Re: patch-log sizes

[Tom Lord]

    > From: Miles Bader <address@hidden>

    > On Wed, Dec 17, 2003 at 12:14:10PM -0800, Tom Lord wrote:
    > >   ~ tla compress-logs [-u] [namespace-region]
    > >   ~ tla compressed-logs

    > > Perhaps also in the various places where libarch/patch-logs.c uses
    > > safe_access to check for the existence of some part of a log, that can
    > > be abstracted to log_access which does the same thing but additionally
    > > prints a warning (perhaps even auto-uncompresses?) if the region of
    > > the patch log in question is missing but is or might be there among
    > > the compressed logs.

    > Are you thinking that the `compressed logs' should be still able to be 
used
    > for merging, etc?  

I'm thinking that it would not be impossible to do so -- not that I'm
certain it's a good idea.   

The logs-as-meta-info uses could be captured pretty simply, as I said,
by beefing up libarch/patch-logs.c.   The logs-as-files would require
a tiny bit of work in {make,apply}-changeset.c.


    > That seems more difficult to me... 

But tractable.  I only wanted to put the idea on the table -- not to
endorse it.

In contrast, an otherwise orthogonal (not interacting with merging or
patching) compresse{d,}-logs seems unambiguously harmless to me.
Useful even, to make a standard way to do a simple and useful
transform on patch-logs.


    > as I wrote in another message, I'd be very happy with `browse
    > only' old logs -- 

There's no essential difference between "browsing" (as in `tla logs')
and "influencing merging".  Logs which are browsable (without using
special commands) are also going to influence merge operators -- and
if we go that far -- then we might as well bite the bullet and deal
with them in changesets as well.


    > if you really wanted to do some merging with a years-old branch,
    > you could just unpack the logs using whatever handy commands
    > there are, and otherwise it would be the same as if you had
    > deleted the logs entirely (which seems to be considered a safe
    > operation, if you don't need them for merging, and don't care
    > about history).

    > If the old logs _are_ `browse only', then maybe the term
    > `compressed' is slightly misleading -- it implies to me that the
    > storage format is changed, but not the semantics.  In this case,
    > I think a term like `decommission' would be better; it makes
    > clear that they're not going to be used in normal circumstances,
    > but are still somehow present.

-t