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

[John Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Parker, Ron wrote:

|>From: John Meinel [mailto:address@hidden
|
|
|>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 don't think this is any problem for now. Eventually you'll probably
want to change that. I'm in no hurry.

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

I thought the whole point of out of tree builds is that it doesn't do
this. But it sounds like it might just be patch not properly supporting
out of tree builds.

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

Well Leroy did the change for adding {revlibs} as a path that gets
compressed. My work around was to just call my revlib "{archives}". I'll
probably switch with the new release. I probably wouldn't use =dirnames,
because a revlib wouldn't have it there to start with. Although I
suppose you could always 'touch `tla my-revision-library`/\=dirnames'

Do people use remote revlibs? I could see a Samba shared source
checkout, but I didn't think a revlib would be used that way. I don't
think revlibs are multi-process safe, so two people working on it at the
same time would cause problems.

I do like the idea that =dirnames signals to whatever arch is running
that it should switch modes. Especially if your idea is to allow people
to publish pathcompressed archives. The only problem is knowing that you
should create the =dirnames in the first place.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA5YO4JdeBCYSNAAMRAh9WAJ0UO0Em3FWnCdL6yNM+KlJRJxAeiACfTeAT
Tpmsrm7V2fuR7j2nFZylI0E=
=dV1r
-----END PGP SIGNATURE-----