Introduction

So as per the instructions on the web page, here's my introduction
message.

My name is Garrett Rooney, and I'm a Senior/Grad Student (almost
graduated and almost a grad student) at RPI majoring in Computer
Science.

I've become interested in version control, and subversion in particular
after reading Greg Stein's diary entries on advogato, and spending a few
hours looking over the web pages and code repository. It seems like a
really interesting problem, with great potential for helping a lot of
people get a lot of work done. In lurking on FreeBSD mailing lists,
I've heard a lot of bitching about cvs, and in my own experience it is
at best 'quirky' and at worst painful. It looks like you guys are on
your way to doing better, and I'd like to help.

For now, I'm just trying to wrap my brain around the design and the
present state of the code, but in the future, assuming I have the time,
I would be interested in coding, discussing ideas, and eventually in
testing early versions of the project.

I imagine that for the time being I'll be mostly lurking, but I do have
a few questions, just from perusing the code over the past day or so.

First, you seem to be useing some data structure called a 'baton' in a
lot of places in the code. From what I can glean from the code, it
seems to just be a data structure that is passed around to represent the
various characteristics of an entity in the repository (say a directory
of a file or somthing like that).

Second, in order to track revisions of a file over copying and renaming,
it seems that the actual copying/renaming needs to be done through
subversion (and the README for the client seems to support this,
although code for these actions does not appear to be present in the
client as it stands. perhaps i could contribute something here, as it
seems straitforward enough.). Now personally, I can't come up with any
way around this that isn't absurdly complicated and error prone, for
example comparing new files to existing files in the tree and looking
for close matches, so maybe there just isn't a good way to do it, but it
seems that requiring this is just going to mean that these revisions are
often going to be untracked, because users will do a rename or copy and
then simply add the file later, rather than going through the trouble of
redoing the copy through subversion, or moving it back to the old name
and renaming it again through subversion. If there isn't a good
automated way to solve the problem, at least it seems like it might be
worthwhile to add commands to the client to allow a user to
retroactively insert the data needed to track these revisions into
subversion. Now that I start thinking about this, I'm not sure exactly
how it could be done, but it's just something that occured to me.

Lastly, I'd just like to compliment all of you on the quality of your
work so far. I don't believe I've ever encountered an Open Source
project with such clear, well documented source code, ample
documentation in the tree, and good instructions on where to start
reading in order to get a good understanding of the code. You've really
gone the extra mile to make the project easy to contribute to.

-garrett

-- 
garrett rooney                           my pid is inigo montoya.
rooneg@electricjellyfish.net             you kill -9 my parent process.
http://electricjellyfish.net/            prepare to vi.