Re: arch

On Sun, 2004-02-08 at 12:10, Henrik Nordstrom wrote:

> a) Prefetch changesets while processing.

Thats certainly possible. Currently the core code is single threaded,
but if we

> b) What about a having local cache of already fetched changesets, similar
> to the revision library?

then we could populate that via a child, and read from it.

We actually have a bigger problem which is round trip latency - we don't
pipeline much if anything. If we address that, I think you'd find
performance jumps by a factor of 3 to 4.

> > There is a user space library that will prevent corruption on linux by
> > breaking hardlinks IFF a file linked into the library is opened with W
> > bits...
>
> Having the library files read-only would probably be wise as well. Same
> userspace library approach can be used to mask this to editors etc.

Erm. This is not easily possible. tla supports diffing mode bits, and
the library mode bits matter.

> And if it were a little more smart in hardlinking the pristine source
> trees to the library when possible then there would not be much issue.

I.e. have the pristine hardlinked, but not the source? Thats possible,
but IMO not really beneficial. The userspace library prevents accidental
corruption, and the improved signature verification in my integration
branch should catch all alterations to the library.

> In addition there is room for a lot of improvement of the library
> management. The inode-sigs are fundamentally broken today causing more
> harm than good, and there is no detection of duplicate files. Have given
> my thoughts in the relevant bug report.

Again, I'll read it shortly... Duplicate files should already be caught
in my integration branch.

> But what I mainly question is why the working directory needs to keep a
> copy of the complete log history of the current tree and all branches it
> has merged. This information can be retreived from the archive if needed
> and is not normaly needed in day-to-day operations.

It's essentially a cache. We do use that metadata heavily in merging and
branching operations. Compare with bitkeeper which keeps all the
patches, not just the metadata locally.

> > And in progress there are plans to allow a binary storage of some form
> > for the logs that you might otherwise trim, if you still want access
> > from the current code to them.
>
> This sounds like something along the lines above? If it is then great.

Yeah, something like that :}. It's not fully specced out yet.

> > > Another unrelated note: Your squid--HEAD--3.0 branch is not up to date. Is
> > > missing some minor changes from beginning of January.
> >
> > Oh! Do you know which changes?
>
> The last revisions of src/cf.data.pre (1.344) and src/errorpage.cc (1.194)
>
> There is also issues with the CVS revision tags. Most files are arched in
> -kk form, but not all. I would propose that the arch tree keeps the CVS
> revision tags intact making it easier to track the two trees.

I'll look into both of these.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.