On Saturday, December 21, 2002, at 02:43 PM, David Summers wrote:
>
> If it needs to be a separate script or program, that's fine. It just
> looked like it fit into the "svnadmin dump/load" structure very well.
>
> 1. It's neat, new, and I'm learning it and using it on projects at
> work.
> :-) (we're converting our simulators to use XML config files)
"it's neat" is not a valid reason for a new feature that doesn't
provide any additional functionality.
> 2. It is a "standardized" way of presenting data in a portable format.
it's only standardized if you're using some standard xml format.
inventing your own doesn't count. this RevML thing might qualify as a
portable format, but a custom xml format does not.
> 6. It seemed the "Right Thing To Do (TM)" :-) coming from a Computer
> Science / Computer Engineering background.
well, unless you've actually got a reason for it, then it's the "Wrong
Thing To Do (TM)" as far as i can tell (also coming from a Computer
Science / Computer Engineering background).
> 7. It looked like a fairly easy way for me to jump into learning the
> Subversion source code while providing something useful. I've
> already
> learned a powerful lot just by running into problems and solving
> them
> (I spent all day re-writing 30-40 source code files to handle the
> change, come to find out that was a very dumb way of doing it and is
> what "batons" were designed for).
honestly, unless you've got an actual problem to solve with this
change, i don't see the point. supporting this RevML thing /might/ be
a good idea if it doesn't take too much work and doesn't clutter up the
existing code too much, but supporting some arbitrary xml format for
something that only needs to be read by subversion itself doesn't make
sense to me.
if you're looking for a way to jump into learning the code, i suggest
picking up a bite sized task from the bug database, there are plenty,
and they give you a good way to learn the code while solving real
problems.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 21 20:56:26 2002