ls*, markup and other things

[Alexey M. <mo...@no...>]

Well, yesterday I committed lsmodules subcommand so everyone are welcome
to test it :-). Together w/ ls, lsacl and forthcoming lstags (Alex,
don't shy as you said me a while ago, commit it please :-)) there's a
complete (hopefully) bunch of commands that implements a kind of listing
server (well, Michael, it's not completely 'httpd'-server as you asked
but it's enough to build a remote web-frontend).

I have already implemented a kind of such frontend based in CVS::Remote
perl module and I hope I'll turn it eventually into viable replacement
of the cvsweb and similar programs).

There's an issue I want to discuss though. Current format of ls*
commands are humanly readable and understandable but they can be more,
hmm, formalized or smth (especially lsacl, but ls also has portability
bottlenecks and so on). So my question is:
do we need these commands to have an, hmm, XML-like output? If yes,
what's the DTD? There're pros (we won't need an unique parser for each
command) and cons (the server code needs to be more complex, there will
be greater output size and so on) so final decision should be carefully
discussed.

Now I'm going to commit cvs-create-repository and cvs-group
commands. Alex, where's the best place to put such things?

A while ago my Novosoft bosses (actually it's Marod :-)) told that would
be fine to have a workaround against one well-known cvs (librcs)
bottleneck: when file processing time dramatically increases when
there're long/complicated commit history. One possible solution for the
problem is to implement (in a separated utility) a kind of purge/merge
operation. This will allow us to remain compatible w/ stock cvs and
solve some of the problems. The question: is there another, more
convenient way? Or we should change the repository format instead and
solve the problem completely?..