Hi guys -- I've started looking at rapidsvn, and I wanted to throw
some feedback your way. Obviously, none of this is meant to be a
personal attack... just pure constructive criticism from an outsider.
First, I think steps need to be taken to "lower the barrier" for other
people to contribute. There are a few simple policies that Subversion
itself has followed from the very beginning, and I think these
policies have a made a *huge* difference in increasing the
user-friendliness of the code. Certainly, nobody is going to tell you
how to run your project. :-) But you should still mull these ideas
over, give them some thought:
* 80-column code formatting. Not everyone in the world uses tiny
fonts in an editor that takes up the whole screen.
* Using spaces for all indentation, instead of tabs. We have
support-files that give us this behavior in Emacs and vi. It
keeps the code looking clean and neat, no matter how you're
viewing it. Most modern editors will do the Right Thing and keep
code aligned as you work, even when indentation is all spaces. At
the moment, a lot of your code looks weirdly misaligned.
* Choose a log message policy. I already see some vague messages in
your log; it's not really clear what happened in every commit. I
shouldn't have to force myself to run 'svn log -v' or 'svn diff
-rN' to figure out what people did. The Subversion project uses a
log policy documented in our HACKING file; or maybe you want to
make up your own. Just avoid ambiguous log messages -- choose
some policy!
* EOL style: some of your source files seem to have CRLF endings,
and some just have LF endings. If you have a lot of
cross-platform developers, you probably want to set
'svn:eol-style' to 'native' on everything. CVS does this by
default, but SVN does not. If you don't set this property, I fear
you're going to end up with a lot of flip-flopping of eol styles
in the future.... which means you won't be able to see changes
when you run 'svn diff'; the *entire* file will look changed.
* Commit policies. Choose some that you like, and stick with them.
For example, a first good policy is to make sure that HEAD always
compiles cleanly. This kind of discipline really pays off; when
somebody checks out the latest rapidsvn code and it fails on a
syntax error..., they get very frustrated. (Which is what I'm
getting right now, by the way...) Continuing on this theme,
another good policy is to make sure that HEAD always compiles
against the latest Subversion API. People are making commits to
the main Subversion code every day, and the API won't be frozen
until 1.0. Two days ago, I couldn't compile rapidsvn because the
interface to 'svn_client_status' had changed since Alpha, and
apparently no rapidsvn developers had noticed -- they were still
using week-old header files! I'm not saying that you need to
stand by, nervously waiting for the svn API to change, ready to
instantly patch rapidsvn; instead, if you're about to commit a
change to rapidsvn, make sure that your working copy compiles
against the latest svn libraries. At least that way we can
backdate our svn libraries to the date of the last rapidsvn
commit, and know it will work!
Second, I have comments about the actual content/design of rapidsvn.
These are purely personal opinions, just my first impressions:
* It seems strange to me that you've got a big window pane that is
essentially showing the output of 'svn st -v': the working
revision, the last changed rev, and so on. But the *whole* point
of 'svn status' is to show the "status" of a file: is it locally
modified? Is it in a state of conflict? Is it scheduled for
addition or deletion? Instead, I have to push a button (or
right-menu-click) to run "status" on the individual item. I don't
understand why the the status enum isn't being used and displayed
right there in the main list; svn_client_status() is giving you
everything you need already. (And every other svn GUI I've seen
is doing this.)
* I also don't understand the output-scroll area at the bottom of
the screen. It looks (at first glance) like you're just capturing
the output of the commandline-client as it runs! After playing
with it a bit, I can tell that's not really true... but I still
don't understand the motivation. Why are you trying to mimic the
output of the commandline program? Why would a GUI user want to
see little U's and G's flying by during an update? I think you
should be making use of the *GUI* somehow. Make the updated items
light up in different colors. Mark conflicted items as red. And
so on. I'm just encouraging you to think "beyond the commandline
box." :-)
Anyway, looks like you guys are off to a good start. I hope this
feedback was useful!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 30 00:24:51 2002