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

Re: scheduling, and gui clients (Win, Mac)

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-11-23 01:09:53 CET

On Wed, Nov 22, 2000 at 06:44:41PM -0500, Mark Murphy wrote:
> Greg Stein wrote:
> > SourceSafe is the only other GUI-based version control that I've used, and
> > it is quite nice. I'd hope to see something like that, than the
> > continuation
> > of bastard UIs like WinCVS.
> I have a fair amount of experience with SourceSafe and have a copy lying
> around here somewhere. Obviously, the two products have quite different
> models (e.g., pessimistic vs. optimistic locking), but I can
> compare/contrast them when working out a proposed GUI.


> Have you had success with any of the other CVS GUIs? Subversion is closer in
> operation to CVS than SourceSafe, so I'm giving CVS GUIs additional weight
> in design considerations.

Not at all. I use the command-line on my Linux box. The couple times when
I've had to use WinCVS, I regret it. I've also had some experience with it
in the past week, setting it up for my partner Anni. Thankfully, she has had
experience with the CVS command-line because it would otherwise make the
thing quite unusable.

> > I imagine part of WinCVS's problem comes from how it wraps around the the
> > CVS client with minimal change.
> I'm willing to bet the author of WinCVS looked upon that as a virtue. If my
> understanding of CVS history is accurate, the GUIs came on well after CVS
> was in wide use. If so, making the GUI work like the command-line client
> would accelerate adoption.

Nah. I'm guessing he didn't want to crack into the CVS client code too much.
If he did choose to stay as close to the cmdline model as possible, then he
is sadly mistaken in how to build a good GUI :-)

> > As a result, it propagates the
> > I/O messages
> > and its working model (e.g. select a particular command to do this/that).
> > With a proper UI, there are many intuitive ways to avoid that nastiness.
> I understand the note on I/O messages. While I like the transcript pane, it
> should be toggle-able on/off, proabably off by default. Or were you
> referring to something else?

Some of that reporting is quite nice, just as a summary of what happened
when you do a recursive commit or update.

I'm referring to the fact that it is very text-oriented. That it duplicates
the exact CVS output, rather than using a format suitable for a GUI. Hell...
go into WinCVS and select the "Status" menu item. Dialog box? Fat chance.
You get text output. Do it for a directory? Scrolling text hell.

Do a commit? You see the "cvs commit -m"message" ..." line in that box.
Urgh. That is just foolish. A commit should ask for the data in a dialog,
then simply update the version number you see in the browsing pane. There
shouldn't be any output in the "transcript pane" (to use your phrase). If
something goes wrong, then a dialog should appear.

That pane should really only be used for batch operations. Even then, I
could easily see a modeless window with the results. The user could then
flip back and forth between that window and the main UI browser. Maybe do
some additional operations (which is why the separate window is nice: those
extra ops wouldn't blast your batch output), and then finally close the
output window when done. Oh, and the files listed in the output should be
"active" (e.g. right-click context menus).

> I'm not sure I understand what you mean by "its working model". Could you
> elaborate?

It is weighted around the CVS command line, rather than natural actions on
the UI itself. The context menus are poor to non-existent, and the selection
model is brittle. The menu structure is atrocious (poorly organized) and
again focuses around CVS's model of "login to the server and cache that; now
go do a checkout; now you can tweak some files; oh, but over there are the
admin actions". The user model is just bad for a UI app.

Ideally, you would have two panes, much like Windows Explorer. A tree pane
on the left, and a files pane on the right. That's it. For some operations,
a modeless window might appear (e.g. batch operations, version tree
diagrams, diff output). I would not recommend MDI (and I believe MSFT is not
recommending it any more either). And I say modeless because it would suck
to have things like a diff be a modal dialog.

etc.... :-)


Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:15 2006

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