Re: [Quilt-dev] [ANNOUNCE] Quian

[Andreas Gruenbacher]

On Tuesday 20 September 2005 23:17, Jean Delvare wrote:
> Hi Andreas,
>
> > >   http://jdelvare.net2.nerim.net/quian/2.6/
> >
> > Quian relly looks nice!
>
> Thanks :')
>
> > I'm eager to learn how much cpu and I/O bandwidth Quian consumes, and
> > how fast it feels locally ;)
>
> It's rather hard to evaluate the bandwidth, as it depends on many
> factors, such as the number of users, the actual use (frequency and
> nature of requests), the average size of source files, the number and
> sizes of patches in the series, etc.
>
> The setup I pointed you to is powered by my home server, that is, an old
> Pentium III at 800 MHz with 256 MB memory and a 256 kB/s network
> access. From your question, I can guess it felt a bit slow.

No, it wasn't really slow.

> This remains viable for casual use and a limited number of users, methinks.
>
> Locally, I just tried on a reasonably fact machine: an Athlon XP 2400+
> with 512 MB memory and 100 Mb/s network access. In these conditions,
> Quian use qualifies as smooth. With a 65 patch series (44.7 MB in bz2),
> navigation is immediate, annotated file view is below 0.5 s (up to 1s
> for really large files), highlight is almost immediate (thanks to
> disk/system cache I presume), file diff is between 1 and 3 seconds
> depending on the file and patch, files list is the slowest operation,
> typically between 3 and 5 seconds.

We could use $(files_in_patch ...|sort) instead of 
$(files_in_patch_ordered ...) in the files command. I'm not sure that the 
ordered variant is very useful for the files command.

> It should be possible to improve the performance by not using bz2
> patches. Most commands seem to be unaffected but at least the files
> list (files.php) should be. The actual benefit obviously depends on the
> CPU/disk speed ratio of the server.

Shouldn't be necessary (see above).

> > One thing we might want to add to quilt annotate is a view that
> > displays the patch names side by side with the source code as Quian
> > does. I so far didn't bother doing that because the code for figuring
> > out how to properly align things scared me off. (Still shouldn't be
> > more than a few lines of shell code...)
>
> I agree it would be convenient to have that in quilt, maybe as an option
> though. Beware that in Quian I convert the patch names to versions
> (remember I wrote it with Linux version patches in mind), but in quilt
> the annotations are likely to be much longer than that, so the annotated
> source may end up being very wide. If quilt can do that, it will save
> some code in Quian and, more importantly, it will let me generate the
> HTML page on-the-fly rather than buffering the entire quilt annotate
> output as is currently needed. It might improve performance a bit.

We can try that.

> > Another would be to somehow get annotate to print which modifications
> > are "underneath" the most recent modification, in case that's useful.
> > Deletions might be interesting as well.
>
> My approach to this problem has been the -p option of annotate. If the
> user wants to know what happened before the version currently displayed
> for a given line, he/she can ask for the annotated source as it was
> right before that change happened. I think it's more realistic, as the
> list of changes which have affected a given line, without the context
> in which each change happened, is not such a valuable information IMHO.

IMO the two are quite different views.

> > > 1* File moves are not handled. As moving files around happens
> > > frequently in the lifetime of a large project, some history is not
> > > visible using Quian. I have plans to improve quilt's annotate
> > > command, but it sounds like a quite complex task, as patch files do
> > > not clearly notify file moves.
> >
> > You won't get that information with patch based tools, and I don't
> > think it makes a lot of sense trying to reconstruct this information.
>
> I think it does, simply because I have an immediate need for it ;)
> Detecting the moves is not that complex, a few heuristics will do.
> Doing it fast and reliably is more of a problem. Integrating this in
> quilt's logic is the most difficult part. I'll give it a try eventually.

Until proven wrong, I'm against adding things like this.

Thanks,
Andreas.