--- Ben Collins-Sussman <sussman@collab.net> wrote:
> 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:
First, let me give you some history of the project. The original
code was developed by Paul Marculescu. He happened to do a very good
job on the project and he has made the most complete product to date
with virtually no guidance from the Subversion team.
I intend on making RapidSVN an example of good iterative design.
Paul's effort was to develop a usable tool as efficiently as
possible. I believe he succeeded. Now it will be RapidSVN team's
job to complete the work by iteratively making the interface better.
> * 80-column code formatting. Not everyone in the world uses tiny
> fonts in an editor that takes up the whole screen.
I didn't know that this was an issue any more. I will certainly look
into this.
> * 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.
This is a pet peeve of mine. I will definitely get this switched to
spaces.
> * 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!
I am not sure which one or ones your are referring to. I'll take a
look.
> * 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.
That is a valid concern. Unix style it is then.
> * 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!
Saying that the Subversion client API is a moving target would be a
great understatement. Just yesterday RapidSVN was building fine.
Today yet another API change surfaced that prevents a clean compile.
I want to be up to the minute as well but without a ChangeLog of API
changes it is difficult to keep up to date. Maybe this process can
be improved now that clients other than svn are dependent on the API?
> 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!
These are all good suggestions. As I said above, iteration of the
code is a key here. Please keep the suggestions coming!
Best regards,
Brent
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 30 04:59:51 2002