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

[John Meinel]

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

Thanks for replying.

address@hidden wrote:
| I know it's slow... I first wanted to be sure this is not a dead end
| development path. I'm actually more in favor of Johannes Berg's work to
| make tla stand-alone, independent of cygwin, but that
| needs a lot of work.
| (see http://wiki.gnuarch.org/moin.cgi/tla_20win32_20todo)
|
| Also, using DOS 8.3 names (you know C:\PROGRA~1\TLA\... )
| should do away with the need for =dirnames.
|
| The real problem is that this approach is (to my knowledge)
| still not  working 100%, but no-one cared enough to give feedback
| on what does not work, so I stopped pouring time into tla, although
| I still keep an eye on it.
|

Well, I haven't been giving feedback, but that's because it works for
almost everything I need. The only times I have a problem with it is in
an initial checkout. Because I don't believe you pathcompress on the
initial get, and those can get pretty deep.

The only other issue was that revision libraries aren't path compressed,
but I worked around that by creating the revision library as ../{archives}.

| [there are places where directories get renamed, moved etc. that might
| move a dirname-mapped directory into a non-dirname-mapped directory. (the
| DOS 8.3 names hack could solve this too) Also the dependency on
| inode-numbers is flakey, since moving files/directories on win32 does not
| preserve inode numbers, i think]
|

Well, I can't say for sure. I might have had some problems when I moved
directories around, but in general that doesn't happen.

| Anyways, I'm not using {arch}, so I don't need it, and if it doesn't
| work in win32, it's useless to me...
|

Well, it doesn't work natively (depending on Johannes work). I actually
prefer a cygwin port because I use cygwin all the time for things. And
I'd rather run my customized bash shell then his zsh.

| * Are you actually using tla on win32, or just wanting to? *
| I was convinced no-one actually uses tla/cygwin.
|
I've been using it for quite some time. I had some problems originally
(the checkout, etc). But as a workaround I changed my archive name
(address@hidden), and that helps quite a bit. I also had to make the project
names shorter (shared-blah-blah -> shrd-blh-blh). But I made it work.
|
|>it might be wise to add some sort of caching. So that
|>we maintain a memory map for any =dirnames files that
|>we've read, so we don't have to read them again.
|
|
| Caching the result of pathcompress_compress_path and
| pathcompress_uncompress_path should be easier to add,
| and have high payoffs as well... it just does not solve the
| underlying problems.
|
|
|
|>I'm willing to contribute some time & code to adding it, but
|>at least right now I don't have the tools to compile tla for cygwin.
|
|
| all you need is gcc for cygwin,
| and you already need cygwin to run tla/cygwin,
| so that's a poor excuse...
|
|
|>Does this sound reasonable? I will probably try to create
|>projects for tar,diff,diff3, etc. Just so that I can get it all out
|>of arch instead of downloading the source code each time.
|>Is there an "official" archive for these programs?
|
|
| the official archive is gnu.org
|

I was actually asking if there was an {arch} archive for these things. I
realize gnu.org has the official releases. But if I'm going to be
"patching" them, I was probably going to do the "arch mirror of CVS"
stuff. So I get CVS head, or possibly a release branch, add that as an
arch branch (tar--official or tar--CVS), and then create a tar--arch
branch sort of thing. That way when there is a new tar release, it just
goes into tar--official, and then star-merge will handle most of the
patching.

I did find one at
http://sourcecontrol.net/?m=showarchive&address@hidden,
and another one at
http://sourcecontrol.net/?m=showarchive&address@hidden

So maybe I'll try to converse with Johannes as well. I agree that his
work seems interesting, but it didn't seem quite as far along as yours was.

|
|
|
|
- 
----------------------------------------------------------------------------------
| Plaats je zoekertjes GRATIS op AdValvas
| Placez votre petite annonce GRATUITEMENT sur AdValvas
| http://www.advalvas.be

As a short-term simple fix, would it be possible to change all the
#ifdef LOG to a configurable parameter? I've been running a logging tla
for a while, and when I remember I end up cleaning out a 400MB log file.
If it's not really easy, then perhaps you could recompile without LOG
defined? If you want, you could put two links on your website, one with
logging enabled, and one without.

I did start looking at your patches, and so far I haven't really figured
out where some of them apply. I assume I need to start with a dist, not
just a tla branch. Is that correct?

Thanks for noticing, and thanks for your earlier work.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA4tyGJdeBCYSNAAMRAoEnAKCTg4XgAYTmvnaX2LlPE8rhjWw0BgCfQzb5
mc1FTCTlsz4dlVhp+L5Xecc=
=JkCu
-----END PGP SIGNATURE-----