gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] tla-1.3.1/cygwin segfaults


From: John A Meinel
Subject: Re: [Gnu-arch-users] tla-1.3.1/cygwin segfaults
Date: Thu, 14 Jul 2005 14:05:11 -0500
User-agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)

Berni Joss wrote:
> On Wed, Jul 13, 2005 at 12:49:15PM -0500, John A Meinel wrote:
>
>>Where did you get 1.3.1? Just trying to figure out which exact version
>>you are using. Unfortunately with the cygwin port, there have been many
>>different attempts. I will start with assuming that you got my version,
>>but it is probably more likely that you got Lode's.
>
>
> Yes, you guessed right :-)
>
>
>>Honestly, though, I have stopped working on tla-1.3.1 for cygwin. I'm
>>the only one who seemed to actively use it, and I switched to working on
>>a version of baz instead. Specifically, you can go to:
>>http://bazaar.canonical.com/Downloads#head-98111c31e4494c307c7344a4897c708faf632e81
>>I try and keep it up-to-date with the latest development version of baz
>
>
> Thank you!
> The baz-dos-1.5-beta43 worked flawless on my tree, and it seemed faster
> too.
> I was not aware baz had been ported to cygwin!

I took Lode's dos filename work, and added it to baz. At the same time,
I added a caching layer to the filename lookups, so in theory it has to
hit the "win32_alt_filename" lookup less.

Not to mention the Baz people have been working on general speedups.
(Caching the stat results, etc.)

It hasn't been officially announced yet, because it has only been done
to baz-1.5 which has not been frozen yet.

(One really nice speedup feature for baz-1.5 is that if you use a
revision library, it will automatically update the revlib on commit,
rather than having you download the patch again.)

>
> Thank you, and the other contributors to tla and baz for these excellent
> tools.

If you have any problems, let me know. As I mentioned, the port is
generally non-invasive, so there shouldn't be much in the way of bugs.

One thing you will have to watch out for. Because this version uses
fully expanded filenames, you can easily get directories that are longer
than 256 characters. Which means that most tools cannot be used, even to
delete them. So you'll notice that I included a pc-rmrf and pc-rmrf.py
scripts. Basically those act like "rm -rf" except they handle paths that
are too long (if the delete fails, they move the long path to a shorter
one, and then try again until it succeeds).

The python script is slightly smarter, and noticeably faster for certain
trees. But it requires python, which you may not have installed. (You
definitely have bash,rm,mv,etc installed).

I'm glad it works for you,
John
=:->

>
> Berni
>
>

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]