RE: [Gnu-arch-users] Dirname caching for leroy's tla on cygwin

[Parker, Ron]

> From: John Meinel [mailto:address@hidden

> But in the meantime, I'm curious to see your work. Is it based of of
> Leroy's?

Yes, it is based on his work.  I have basically used a config to pull all
the standard tla stuff, with some version of his patches, together with
diff, patch, and tar.  It can all be built and configured in one shot.

> What changes have you made?

Primarily changes to adapt the GNU packages to integrate with
package-framework.  Basically, I tried to make step-wise changes from
Leroy's patches to an integrated build tree.  

I realized last night that I have not pushed the original
diffutils--mainline branch to my mirror, but it was tagged into
diffutils--tla-cygwin.  If you want this, pushing it will have to wait until
after the holiday weekend.

> I'll read up your patch logs and
> such, but it would be interesting to get sort of a summary from you.

I am currently attempting to integrate the pika-escapes support, so that I
can use the code for stuff at work that *mumble* has spaces in the file
names.

Some basic clean up is still needed, for example some of the doc files for
patch land in the install tree and the configure/make process leaves
modified files in the src/patch tree, a wonderful side-effect of the
autotools that I have not figured out how to work around, since it seems to
vary from machine to machine.  If I check in the changes from Linux, my Mac
or Windows box still changes those files to something different.  This makes
reviewing commits ahead of time necessary to avoid extraneous patches.

Also revlibs are not currently working as there is no support for
pathcompressing them.  My thoughts on this are to either:

1.  Have the presence of =dirnames indicate that a given tree should be
pathcompressed.  
2.  Add a setting to ~/.arch-params
3.  Scan ~/.arch-params/=revision-library

The first seems, in some ways, the simplest.  But it would preclude
=dirnames from ever being used for anything else.  This may be fine, as I
cannot think of a non-arch instance of this name, but that may be a bad
assumption.  One advantage is that the directory itself would carry with it
information that it is compressed and so would not require per-user
configuration.  This seems least likely to lead to inconsistent behavior and
would allow a non-drain-bamaged system to still understand the {arch}
directories of one that is brain-damaged.

The second would allow the user to control which additional directories are
pathcompressed, via a different mechanism.

The third just handles the revision-library instance as a special case, and
I would need to be careful to only pathcompress local file-system revlibs
and not remote revlibs, e.g. a hypothetical revlib on a Samba share for use
in a development group.

Input on this (or any) aspect of pathcompression is most welcome.