On 6/7/07, Peter Lundblad <email@example.com> wrote:
> Erik Huelsmann writes:
> > If we're going to change the WC format number, I'd like to replace the
> > current log processing system (which uses XML) with a different one
> > which uses the tuple system also used by svnserve.
> > Major difference is that if we don't use the XML format anymore, I
> > expect both parse time and time for generating the logs will go down,
> Do you have any profiles to back this up? My concern is that the things
> we do that generate logs are quite file system intensive and it is not clear
> to me that the CPU usage is important. I'm happy to be proven wrong, though.
> > and - the best of all - we can't forget to encode fields, we'll just
> > serialize internal data structures and reload them again in a much
> > more straigt forward way.
> We also have a format for tuples used in the entries files. We could make the
> routines that read and write entries files more generally useful.
> I don't see any real disadvantages/advantages regarding either formats.
> It is just that it might be better to use similar formats throughout the
> WC admin area.
I've given this quite a bit of thought and I started to mention the
ra_svn tuples because they match (in structure) quite closely what we
have now in XML: a command structure with flexible arguments. Not all
log-command generators know about the different arguments that they'll
be passing to the command (in name or number) because they're passed a
hash of arguments.
It's harder to implement the same thing in the entries format we have
now. At the same time would it be awkward to start mentioning argument
names in the entries file (apart from wc-format concerns) because that
would cause a lot of duplication.
I also thought about using the ra_svn tuple format, because the ra_svn
strings specify their own size, meaning we can just copy that data
without having to parse the log file byte for byte. (Something the
entries reader as well as the XML parser *do* have to do.)
If the latter point isn't one of performance, then at least I think
it's elegant because we already had the structure in memory.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Jul 25 23:32:54 2007