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 ...
- Dumb permissions system. You can't finegrain permissions gained to individual developers over branches, files etc.
- (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>