Re: cvs2arch (was Re: [Gnu-arch-users] an hack.. one night long)

[wave++]

In local.unid.arch, you wrote:
> On Sat, Aug 23, 2003 at 04:04:29PM +0200, wave++ wrote:
>>   http://www.yuv.info/~wavexx/hacks/cvs2arch-perf.png
> 
> Interesting. Did you by any change disable the pristine tree?

Pristine tree is in it's place.

> Is red a CVS checkin, or a checkout?

In red it's a summation of several cvs checkouts (one per file in the
current cvs patchset); roughly equivalent to a single cvs checkout by
date. I know that a cvs checkin time would be more useful to compare,
but we are going in the opposite way.

> Very interesting how the tla commit time closely tracks the additional
> size of the {arch} directory tree. I guess the only change there should
> be the addition of one logfile, which should be very quick for diff.

In fact, tla should only diff the pristine tree against the local
sources and produce a patch. (Am I missing something?).  This should be
almost constant over time considering that the size of the sources isn't
changing much.

> I don't think that has anything to do with forward or reverse deltas. In
> fact commits should be faster with forward deltas. Only the modified
> data is written to disk instead of having to copy the whole tree to the
> head revision. It is probably not noticable on a 4MB tree, but just try
> to import a couple of linux kernel revisions.

Monday I should be able to get my hands on the work's CVS repository
(over 10k commits). It should be a considerable test for cvs2arch and
tla at a glance (and I do know the CVS history to do some considerations
about general usage).

Is there any handy way to retrieve a particular revision using tla by
date (besides grepin' revisions and choosing manually)?

>> arch @ patch 280 is roughly 8 times slower than arch @ patch 5 in this
>> case.
> 
> Notice how it closely tracks the size of the complete archive, while the
> size of the actual source tree isn't changing much. Either you do not
> have a pristine tree and tla has to check out the last head revision on
> every commit, or something fishy is going on in the code that tries to
> diff the logs for the working directory with those of the pristine tree.
> Only one file should be added and that can not be all that expensive for
> diff although I guess that tla is reading all the data in both trees
> twice, once by tla because of a bad call to safe_stat in libarch/diffs.c
> and the second time by diff because timestamps are not trusted.

Seems like it tries to do something with old patches (like regenerating
the head every time).

I'll now try to profile it and see what happens. I already converted
almost all my cvs repositories without problems.

Meanwhile, anyone aware about a recent "tla tag" bug/issue?

-- 
'(wave++ "Yuri D'Elia" "http://www.yuv.info/";)