Yippie! Finally made XMLRPC export to Advogato working --- I can't say that
either XMLRPC::Lite or RPC::XML is any well documented, the opposite is truth
rather and it took a little of googling and trying random approaches to figure
out how to make at least RPC::XML working reasonably. I have to admit that it
isn't really that ellegant as in Python, though.

Advogato people, please tell me if you will feel that my overly
long, elaborate and boring rants are unappropriate for Advogato and I should
rather keep them to myself (there you could
also leave your opinions in discussion theoretically available near each
entry). Oh and also apologies for the empty entry I have submitted a while ago,
I thought naively that I could delete it afterwards. Hmm, actually I could
implement these two features (deleting of diary entries and discussion attached
to them) in Advogato, what do you think? Would it (especially the discussions)
be feasible?

Aside of the usual IRC idling and submitting new hostfs patch for 2.5 UML, I
didn't do that much today. I started to resurrect my activities (and
unforunately pretty much the only activities) at XS26 a little, repairing some more broken db
entries, taking care about some users crying for a long time already and
playing with few peerings. I think I should finally allocate few days for a
completely rewrite of the software, releasing it as opensource, finishing
support for dialup users and user BGP4+ peerings, fixing up the routing and
bringing XS26 to as much MIPP as possible
and reasonable. So much to do... is it even worth it? Is it going to actually
help enough people?

One of the main problems is actually with the routing software.
Plainly: we use zebra now, and it sucks. The NL PoP which enables our virtual
presence at AMSIX is disabled now due to zebra eating all the CPU there, ospf6d
likes particularily crashing and going into infinite loops as well, bgpd is
probably the least problematic nowadays but sometimes it does strange things as
well. And time by time, the whole zebra suite happens to read from some
blocking fd and hang happilly. Zebra just apparently can't keep up in mixed
Linux/*BSD environment (that shouldn't be much an issue, though) with
relatively big (around 5000 entries) and very dynamic (entries flying in and
out with average frequency of one change per minute or so) routing table, at
least not for us. Hacking it seems pretty ugly job due to nature of the bugs,
which are difficultly trigerrable and unreproducible, happenning seemingly
randomly. But what are the alternatives? I know only of BIRD, which would have
to be told about IPv6 OSPF (we are using OSPF for choosing routes between
individual PoPs and BGP for all the other routes) and the *BSD world.

I've been thinking about some usable enough versioning/revisions keeping
system, when becoming annoyed about CVS for another time and thinking what
to migrate ELinks source
code to and what to use as a suitable platform for tracking of my bunch of
Linux Kernel patches (maybe it will be best done manually anyway, it seems... I
will see yet). Why I don't like CVS again? (sorted roughly by importance)

The concept of changesets (tracking of whole commits and ability to work
with them compactly) is totally absent --- that is particularily annoying
during the daily work and pretty much defeats the version
tracking ideal.

When merging two branches, intermediate history between the branchpoint and
mergepoint of one of the branches is lost, being compressed to one compact diff
applied to the other branch. You lost possibility to individually track the
evolution of the branch, revert various specific changes etc. This flaw becomes
particularily annoying when you are merging with someone else tracking his
working copy of the project privately, so you can't at least go and stuff the
original branch revision numbers to your CVS to get the needed diffs (see also
below about distributed development).
Being able to merge a branch repeatedly without any problems is obviously a
natural requirement as well.

One cannot move and rename files reasonably, I mean without losing
history.

Treating directories too specially, being unable to remove them, move them
etc. Also the directory structure should be versioned if possible. Let me also
stuff here that having 'CVS' subdir crying at you there could be disturbing for
some people :^). I can't see reason why it can't be ./.CVS or ./.cvs ...

(At least partial) absence of metadata tracking --- files permissions and
ownership, in particular. Symlinks and other special files storage is included
in this point as well.

It has problems with binary files. Ie. binary diffs support is
missing.

Ineffecient communication over network, and usually hackish (pserver)
accomplishing of this communication at all.

Absence of distributed development support, where people could easily track
their personal copies of the repository and doing what they need there, then
being able to ask the maintainer of the central project's repository to revisit
their changes and optionally pull them all or only some changesets back to the
central repository, where they would merge intelligently without not losing the
history. Obviously per-branch write permissions and intelligent merging alone
could do, but the branch number could grow in an uncontrollable fashion, the
administrative load would be high (since to be able to benefit from this, each
potential patch maker which would like to have the history tracked would ask
for his account and branch for feature A and branch for feature B) and being
able to work on a local copy of a repository is still incredibly useful (were
you ever wanting to code something when on vacation or in airplane? do you have
dialup connection?).

So I've been also looking around for various OpenSource (yes, the favorite
here would be certainly BitKeeper, which seems to excellently implement most of
these ideas) tools which would be able to accomplish at least a
part of this. Also it should be able to use CVS-compatible
interface at least for an readonly access --- 95% (or more) of OpenSource
people out there just use CVS and I want them to be still able to
easily track the latest ELinks tree.

The first obvious candidate was SubVersion, but the intelligent merging is
mandatory for me and svn looks to entirely miss that kind of thing,
unfortunately; also, I didn't look at the code but I tend to usually trust Al
Viro regarding it ;-). But when forgetting SubVersion, there's frankly not much
out there I've found. There's OpenCM, which misses most of the mandatory
features listed above, though. Looking at Perforce, I've found only marketing
talks and no real list of features which matter. A few other projects lacked
any easily accessible features list at all. Anyway, the promising projects are
Aegis (from what I saw at web, it is almost ideal; its problem is that the
documentation is in .pdf only, which is a highly hostile document format for
me) and arch (I'm not sure if that one would be that easy to have CVS
frontend).

First I've thought about writing some version managment system reasonable
for me from scratch, but now I hope I could adapt and possibly extend (if it
has already the most fundamental features, things like metadata tracking or CVS
frontend [provided that the underlying concepts aren't *TOO* different]
shouldn't be that easy) either Aegis or arch. I will check them out tommorow
and we will see if there will come anything out from it ;-). Do you have any
other tips for good tools? Or any suggestions regarding my working \"Pasky's
Ideal Versioning System Features Specification\"?

Oh, look, I've been *again* writing too much. I should rather sleep, cure
from illness, not forget to take Bromhexin regularly. And...
<center><table border=\"1\"><tr><td>Don't forget to water the flowers!
Don't forget to water the flowers!</td></tr></table></center>