Re: [PATCH 4/5] Overhaul of changeset application
- From
- Eric Wong <normalperson@yhbt.net>
- Date
- Nov 12, 2005, 20:49 UTC
- Message-ID
- <20051112204928.GA31205@mail.yhbt.net>
- In-Reply-To
- <46a038f90511120407y68031071v15244175f6458c54@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
Show 8 quoted lines
> Eric, > > I'd actually like to improve the script to handle directory renames > and file modes correctly so we don't need to ever call the glacially > slow `tla get` -- I don't think it's that much work, all I need is a > sample repo. OTOH, if you think (or can convince me) that there are > more serious problems ahead, perhaps we can have this as an > alternative import mechanism?
tla get is hardly ever called, I don't think it's called any more than before, even. tla replay by far the most common case and still reasonably fast. I had to add the -I flag to rsync because it was going at > 1 patch per second, plenty fast enough for me.
I also had an alternate implementation for using the revision library, but that was slower than the current strategy because it had to do two full Arch tree integrity checks for each patch applied.
Even on a hot (fully filled) revlib and all I had to do was tla library-find + rsync, it ran more slowly, probably because rsync couldn't take advantage of kernel/fs-level caching when it had to work on a different directory each time.
Tracking renamed directories (especially when nested subdirectories are also renamed) is very, very far from pleasant.
> On 11/12/05, Eric Wong <normalperson@yhbt.net> wrote: > > - Correctly parse multi-line summary text in patch-logs > > Was this broken!? I'm sure I've imported multiline summaries!
It only got the first summary line when I tried it. Also, it's possible for hand-made message bodies to fool archimport if it has "headers" after the first \n\n. IIRC, some old tools copied entire logs of merged changesets into the message body.
-- Eric Wong