[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

rapidsvn feedback

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-07-30 00:23:18 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.