You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kevin Pilch-Bisson <ke...@pilch-bisson.net> on 2001/01/30 01:23:25 UTC
Gui Clients
Hey all,
I was thinking of taking a stab at a Java gui, and maybe a Qt/KDE Gui
too, (depending on how energetic I feel), but I was thinking it would be
good if they all look fairly uniform, so does anyone have any screen
shots of what the Windows Gui looks like? You could either mail them to
me or post them on the web somewhere.
Thanks
--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
http://www.pilch-bisson.net
PGP Public Key At http://pgp.pilch-bisson.net
Re: How uniform can GUI clients be?
Posted by John P Cavanaugh <ca...@soco.agilent.com>.
On Tue, Jan 30, 2001 at 02:43:27PM -0800, Kevin Mallory wrote:
> I've not seen the latest emacs/ediff/emerge stuff yet, but you should at
> least look at the merge manager in ClearCase.
While Im a die hard cli guy myself, the merge manager & version tree
viewer (especially the one on winblows nt) are excellent.
> It's one of the best parts of the tool (along with xlsvtree - the
> graphical version/merge browser).
I couldnt live without the lsvtree functionality when I moved from
ClearCase to cvs, so I wrote one. I have a command line cvslsvtree
perl script if anyone is interested.
--John Cavanaugh
Re: How uniform can GUI clients be?
Posted by Bob Miller <kb...@jogger-egg.com>.
B. W. Fitzpatrick wrote:
> Just for the sake of argument, NeXT/Apple's FileMerge utility totally
> blows Emacs away. It's a *very* nice GUI diff/merge program. I can't
> even begin to describe it without pictures.
I haven't used NeXT's FileMerge. I use xxdiff. I like it a lot, to
the point where I can barely comprehend regular diff's output anymore.
xxdiff's ancestors are xdiff and gdiff, which were developed at SGI
for IRIX over the last decade.
http://xxdiff.sourceforge.net/
kdiff (part of KDE) looks a lot like xxdiff, but its behavior is
completely broken.
--
K<bob>
kbob@jogger-egg.com, http://www.jogger-egg.com/
Re: How uniform can GUI clients be?
Posted by RADICS Peter <mi...@lbcons.net>.
On Tue, Jan 30, 2001 at 11:17:22PM +0100, Branko �ibej wrote:
[SNIP]
> > versions. Things that are tricky on a shell prompt and gets easier/nicer
> > within a GUI.
>
> Heh. We've got that. Its called Emacs+ediff+emerge.
>
> (I know, I know, not being constructive ... but I have yet to see the
> graphical diff/merge that beats Emacs in that respect.)
>
I once worked on OpenStep with Project Builder (not sure about the
name). It had a pretty good visual diff editor. If you can get your
hands on a OpenStep install CD, give it a try, and see if it's better
than your emacs beast :)
cheers,
mitch
--
// RADICS Peter <mi...@lbcons.net> (http://lbcons.net)
//
// "If human beings don't keep exercising their lips,
// their brains start working." -- Ford Prefect
Re: How uniform can GUI clients be?
Posted by Branko Čibej <br...@xbc.nu>.
Kevin Mallory wrote:
> I've not seen the latest emacs/ediff/emerge stuff yet, but you should at
> least look at the merge manager in ClearCase.
I have. Several times today, in fact. :-)
> It's one of the best parts of the tool (along with xlsvtree - the
> graphical version/merge browser).
The version tree is absolutely the best part of ClearCase, ans on I'd
like to see in SNV GUI clients. As I've said before.
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
RE: How uniform can GUI clients be?
Posted by Kevin Mallory <ke...@ActiveState.com>.
I've not seen the latest emacs/ediff/emerge stuff yet, but you should at
least look at the merge manager in ClearCase.
It's one of the best parts of the tool (along with xlsvtree - the
graphical version/merge browser).
-- Thanks
Kevin
Kevin Mallory VP, Engineering, 604-484-6474
Active State - http://www.activestate.com - Programming for the People
QUALITY is never an accident; it is always the result of high intention,
sincere effort, intelligent direction and skillful execution; it
represents the wise choice of many alternatives.
This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please
contact the sender and delete all copies.
> -----Original Message-----
> From: Branko �ibej [mailto:brane@xbc.nu]
> Sent: Tuesday, January 30, 2001 2:17 PM
> To: Daniel Stenberg
> Cc: dev@subversion.tigris.org
> Subject: Re: How uniform can GUI clients be?
>
>
> Daniel Stenberg wrote:
>
> >> A GUI SVN client could offer simple diff and conflict
> viewing features.
> >
> >
> > I'd say this is one of the areas where a GUI client can
> show its power. A
> > really fancy diff viewer in different colours or traces
> what was done between
> > versions. Things that are tricky on a shell prompt and gets
> easier/nicer
> > within a GUI.
>
> Heh. We've got that. Its called Emacs+ediff+emerge.
>
> (I know, I know, not being constructive ... but I have yet to see the
> graphical diff/merge that beats Emacs in that respect.)
>
>
> --
> Brane �ibej
> home: <br...@xbc.nu> http://www.xbc.nu/brane/
> work: <br...@hermes.si> http://www.hermes-softlab.com/
> ACM: <br...@acm.org> http://www.acm.org/
>
>
Re: How uniform can GUI clients be?
Posted by Branko Čibej <br...@xbc.nu>.
Daniel Stenberg wrote:
>> A GUI SVN client could offer simple diff and conflict viewing features.
>
>
> I'd say this is one of the areas where a GUI client can show its power. A
> really fancy diff viewer in different colours or traces what was done between
> versions. Things that are tricky on a shell prompt and gets easier/nicer
> within a GUI.
Heh. We've got that. Its called Emacs+ediff+emerge.
(I know, I know, not being constructive ... but I have yet to see the
graphical diff/merge that beats Emacs in that respect.)
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: How uniform can GUI clients be?
Posted by Branko Čibej <br...@xbc.nu>.
Bob Miller wrote:
> Okay, branches are hard, and probably the wrong thing to design first.
> But you could ask the same questions about tags or revisions.
No, branches are simple, if you have a version-tree view, like ClearCase
does. So are tags and revisions. I sent a few screenshots to Bill Tutt a
few minutes ago. I can post them here, or put them somewhere in the
repo, if you're interested.
Whats hard is getting the information out of the SVN filesystem; we
don't have any APIs for that right now. That'll have to wait.
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: How uniform can GUI clients be?
Posted by Bob Miller <kb...@jogger-egg.com>.
Mark Murphy wrote:
> While we may depict a folder/directory differently, the context menu
> operations to be performed on one should be fairly consistent (i.e.,
> add, remove, update all, commit all, ... for a folder/directory).
> Similarly, most of the options off of the window menus should be
> similar. There are still likely to be platform-dependent options in both
> types of menus, but we can probably get 80% consistency. After all, the
> goal behind uniform GUIs should be transferable knowledge (if I know GUI
> A, I can figure out GUI B quickly) vs. absolute identical functionality.
>
> Thoughts?
At an even higher level, thought should be given to what the user-
visible objects and actions are, and those should be the same across
platforms.
For example, what is the representation of a branch? Is it an
explicit object, a bunch of side effects on other objects, or both?
Can I simultaneously view two branches? How do I compare two
branches?
If the GUIs are in agreement about those (and their model is usable),
we'll be doing well.
Okay, branches are hard, and probably the wrong thing to design first.
But you could ask the same questions about tags or revisions.
--
K<bob>
kbob@jogger-egg.com, http://www.jogger-egg.com/
Re: How uniform can GUI clients be?
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Tue, Jan 30, 2001 at 08:36:30AM -0500, Mark Murphy wrote:
> Rather than focusing on the differences, maybe we can start listing
> places where we can be the same.
Good Idea!
> For instance, I think all the GUI environments we've been talking about
> support two main types of menus: window menus (the kind that drop down
> from a bar just under the window title bar) and context menus (the kind
> that pop up when you perform a platform-specific type of mouse click on
> an object).
Yup.
> While we may depict a folder/directory differently, the context menu
> operations to be performed on one should be fairly consistent (i.e.,
> add, remove, update all, commit all, ... for a folder/directory).
> Similarly, most of the options off of the window menus should be
> similar. There are still likely to be platform-dependent options in both
> types of menus, but we can probably get 80% consistency. After all, the
> goal behind uniform GUIs should be transferable knowledge (if I know GUI
> A, I can figure out GUI B quickly) vs. absolute identical functionality.
>
> Thoughts?
Here is what I was thinking of something like the following for the
window menus.
File
Repository - for choosing server/repository/authentication/etc.
Exit - I'll let you figure it out
Edit
Checkout
Update - update currently selected item (if any).
Update All
Commit - commit currently selected item (if any).
Commit All
View
As Unified Tree - view tree Mac Style with folders and files.
As Tree - view Windows Explorer style, tree and pane of files
As ???? - view Windows style where just current dir is shown
---
Differences
Status
Log
Help
The usual stuff.
For context menus I was thinking along the lines of
Update
Commit
Status
Log
Differences
As for overall design, I was thinking of either a two or three paned
thing, something Outlook or Outlook Express. I.e. in my best ascii art.
+---------------------------+ +-------+---------------+
| | | | |
| Hierarchy for unified or | | tree | Files |
| windows style | | | (for explorer)|
| | | | |
+---------------------------+ or +-------+---------------+
| | | |
| Info, i.e. contents, diff | | |
| status, log, etc | | same |
| | | |
+---------------------------+ +-----------------------+
Or, and this would probably be more consisten with Outlook, have the
tree come all the way down on the left, then have the right split top to
bottom with Files, and info.
What do people think about something like this.
Please fee free to add more menu options, move them around, etc.
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
http://www.pilch-bisson.net
PGP Public Key At http://pgp.pilch-bisson.net
Re: How uniform can GUI clients be?
Posted by Joerg Bullmann <jo...@fontworks.com>.
At 8:20 AM -0500 1/31/01, Mark Murphy wrote:
>The only reason for having "foo" and "foo ALL" as separate operations is
>if they have actual different meanings. For example, if performing an
>operation on a folder means something different than performing an
>operation on a folder and its contents.
I understand this difference is whether to perform the
operation recursively or not, right? Is the current (CVS
like) "recursive" or "not recursive" option not better
for this? In this respect, CVS works quite well, no?
> > Well, what would be a GUI operation for "merge from
>> branch rel-1-0-1-fixes"? This could be mapped to
>> drag and drop in a branch and revision history
>> tree view. Good. And a diff between rel-1-0-1-fixes
>> and rel-1-1-a16 of a few files? I'd say, that selecting
>> the files and then picking the diff command from the
>> SVN menu is not too strange a thing. After that you
>> can view the diff of each file by double clicking
>> the files' entries in the sand box view.
>
>I'm not familiar with version tree views, so I don't know how we'd do it
>there. In a file/folder view, when you select a file, I can see a diff
>menu option off the file object's context menu.
With version tree I mean a DAG where each node represents
a revision or a tag or a branch of a file. There you could
drag one branch node and drop it on top of another branch
(or the trunk for that matter) to signal that you want to
merge the dragged one into the one that you drop on.
> > I might be missing a lot here. But one thing is: people
>> will only feel "comfortable" with SVN (or any other
>> complex system) if they can figure out what's going
>> on. They have to understand what it does and they
>> have to understand notions of tag, branch, revision
>> history, etc. And they have to understand what operations
>> they can perform and what those operations will do
>> for them. In a system like SVN, we mustn't expect
>> the GUI to teach the user? Isn't there going on too
>> much that is not immediately *visible*. In this respect,
>> SVN is very different from, say Photoshop, where
>> you immediately see on screen what you do or did.
>>
>> So, what's so bad about having these operations as
>> commands in menus?
>
>I think most "commands" need to be operations against objects, vs.
>standalone commands. In other words, as much on context menus as
>possible vs. window menus.
Totally agree: a "command" works against an "object". That's
it. This is one of the core paradigms of GUI's like Mac OS
or Windows. And it existed and worked well long before Mac OS
or Windows knew contextual menus (no?). A command being in a
menu bar menu doesn't imply that that command is "standalone".
There surely are some: best example is "Quit". But there also
are others: e.g. "Cut", "Paste", "Copy", ... IMHO contextual
menus are great stuff because they save you "mouse mileage".
But conceptually, selecting a file or folder and then moving
the mouse to the menu bar to click there or control clicking
to get a contextual menu are not that far apart. OK, the user's
centre of attention always stays the object if contextual
menus are used, agreed. But I still fail to see the substantial
difference between both. After all, the usual menu bar guides
the user by disabling commands that do not apply to the current
object selection.
Don't get me wrong, I'd love to see contextual menus and
drag and drop operations etc. But the good ol' menu bar with
all commands in it needs to be around also.
Joerg
Re: How uniform can GUI clients be?
Posted by Mark Murphy <mm...@collab.net>.
> >While we may depict a folder/directory
> >differently, the context menu operations to be
> >performed on one should be fairly consistent
> >(i.e., add, remove, update all, commit all, ...
>
> I'd say leave out commands like "update ALL"
> and "commit ALL". The idea generally should
> be: select an object and then specify the
> operation you want to do with it. An object
> here can be a folder or a file or so.
The only reason for having "foo" and "foo ALL" as separate operations is
if they have actual different meanings. For example, if performing an
operation on a folder means something different than performing an
operation on a folder and its contents.
> Well, what would be a GUI operation for "merge from
> branch rel-1-0-1-fixes"? This could be mapped to
> drag and drop in a branch and revision history
> tree view. Good. And a diff between rel-1-0-1-fixes
> and rel-1-1-a16 of a few files? I'd say, that selecting
> the files and then picking the diff command from the
> SVN menu is not too strange a thing. After that you
> can view the diff of each file by double clicking
> the files' entries in the sand box view.
I'm not familiar with version tree views, so I don't know how we'd do it
there. In a file/folder view, when you select a file, I can see a diff
menu option off the file object's context menu.
> I might be missing a lot here. But one thing is: people
> will only feel "comfortable" with SVN (or any other
> complex system) if they can figure out what's going
> on. They have to understand what it does and they
> have to understand notions of tag, branch, revision
> history, etc. And they have to understand what operations
> they can perform and what those operations will do
> for them. In a system like SVN, we mustn't expect
> the GUI to teach the user? Isn't there going on too
> much that is not immediately *visible*. In this respect,
> SVN is very different from, say Photoshop, where
> you immediately see on screen what you do or did.
>
> So, what's so bad about having these operations as
> commands in menus?
I think most "commands" need to be operations against objects, vs.
standalone commands. In other words, as much on context menus as
possible vs. window menus.
Mark Murphy
mmurphy@collab.net
Re: How uniform can GUI clients be?
Posted by Joerg Bullmann <jo...@fontworks.com>.
Mark and/or Daniel wrote:
>While we may depict a folder/directory
>differently, the context menu operations to be
>performed on one should be fairly consistent
>(i.e., add, remove, update all, commit all, ...
I'd say leave out commands like "update ALL"
and "commit ALL". The idea generally should
be: select an object and then specify the
operation you want to do with it. An object
here can be a folder or a file or so.
>for a folder/directory). Similarly, most of the
>options off of the window menus should be similar.
>There are still likely to be platform-dependent
>options in both types of menus, but we can
>probably get 80% consistency. After all, the goal
>behind uniform GUIs should be transferable
>knowledge (if I know GUI A, I can figure out GUI B
>quickly) vs. absolute identical functionality.
Agree with this.
>>I'd say that there shouldn't be a need for a menu
>>with "SVN commands". There's a GUI and the
>>"commands" should be replaced with GUI operations
>>as far as possible.
Well, what would be a GUI operation for "merge from
branch rel-1-0-1-fixes"? This could be mapped to
drag and drop in a branch and revision history
tree view. Good. And a diff between rel-1-0-1-fixes
and rel-1-1-a16 of a few files? I'd say, that selecting
the files and then picking the diff command from the
SVN menu is not too strange a thing. After that you
can view the diff of each file by double clicking
the files' entries in the sand box view.
It is my opinion that any kind of "hidden functionality"
(like merge via drag and drop) needs a visible
counterpart on a menu. That was one of the ideas behind
menus: you can see the commands which are there! This
helps a lot when you are new.
>>Of course, allowing some
>>commands and a shell prompt for power users is
A shell prompt? Do we really need that? Wouldn't this
kind of defeat the purpose of a GUI client? If you
want a command line, you can use the command line client,
no? ;-)
>>still a feature that could be left in there but
>>I'd prefer if the GUI would not feel like just a
>>fancy layer ontop of the SVN command line
>>commands. I'd want that a GUI-user shouldn't need
>>nor have to know the SVN client commands.
>
>Agreed.
I might be missing a lot here. But one thing is: people
will only feel "comfortable" with SVN (or any other
complex system) if they can figure out what's going
on. They have to understand what it does and they
have to understand notions of tag, branch, revision
history, etc. And they have to understand what operations
they can perform and what those operations will do
for them. In a system like SVN, we mustn't expect
the GUI to teach the user? Isn't there going on too
much that is not immediately *visible*. In this respect,
SVN is very different from, say Photoshop, where
you immediately see on screen what you do or did.
So, what's so bad about having these operations as
commands in menus?
Some of these operations will easily be mapped
to e.g. drag and drop. But not all. How would you
e.g. retrieve an old revision 1.5 of file
hungerdunger.mc ? What GUI operation would be an
appropriate and intuitive choice for that? OK, I
might be a tad dry in my imagination here, but
I really think that there should be a menu command
entry for every SVN command. Surely, on top of
that, some commands can be triggered through drag
and drop.
What am I missing? What other GUI operations did
you have in mind? I can think of drag and drop.
What else?
>>>Do we want a log window that shows all the server
>>>responses? I like
>>
>>I'm against it. Sure, it can *exist* if you select
>>to enable it and if you wanna do some
>>prevent the need for a "server log".
>
>I envisioned a log window (a.k.a., "transcript",
>stemming from my Smalltalk days) mostly showing
>exactly which files were affected on recursive and
>wildcard operations (e.g., update). The transcript
>would be toggled on/off, and probably default off,
>but I think it could be useful for batch
>operations.
Yep! Exactly that. Only, I'd have it default to
"on". 8-)
Cheers,
Joerg
Re: How uniform can GUI clients be?
Posted by Mark Murphy <mm...@collab.net>.
> I totally agree that it might be hard to make really intuitive
interfaces for
> different platforms that are uniform and still match the paradigms and
> peculiarities of those particular platforms.
>
> Still, just guessing here, most platforms would probably use the same
> approach and only the Mac would differ.
Rather than focusing on the differences, maybe we can start listing
places where we can be the same.
For instance, I think all the GUI environments we've been talking about
support two main types of menus: window menus (the kind that drop down
from a bar just under the window title bar) and context menus (the kind
that pop up when you perform a platform-specific type of mouse click on
an object).
While we may depict a folder/directory differently, the context menu
operations to be performed on one should be fairly consistent (i.e.,
add, remove, update all, commit all, ... for a folder/directory).
Similarly, most of the options off of the window menus should be
similar. There are still likely to be platform-dependent options in both
types of menus, but we can probably get 80% consistency. After all, the
goal behind uniform GUIs should be transferable knowledge (if I know GUI
A, I can figure out GUI B quickly) vs. absolute identical functionality.
Thoughts?
> I'd say that there shouldn't be a need for a menu with "SVN commands".
> There's a GUI and the "commands" should be replaced with GUI
operations as
> far as possible. Of course, allowing some commands and a shell prompt
for
> power users is still a feature that could be left in there but I'd
prefer if
> the GUI would not feel like just a fancy layer ontop of the SVN
command line
> commands. I'd want that a GUI-user shouldn't need nor have to know the
SVN
> client commands.
Agreed.
> > Do we want a log window that shows all the server responses? I like
it.
> > But I think I recall someone (was it one of the Greg(g)s?) speaking
out
> > vehemently against it some time ago. My memory might fool me here.
>
> I'm against it. Sure, it can *exist* if you select to enable it and if
you
> wanna do some under-the-surface debugging and see exactly what the
server did
> say. But I think that the GUI should present information and progress
data to
> prevent the need for a "server log".
I envisioned a log window (a.k.a., "transcript", stemming from my
Smalltalk days) mostly showing exactly which files were affected on
recursive and wildcard operations (e.g., update). The transcript would
be toggled on/off, and probably default off, but I think it could be
useful for batch operations.
BTW, I am finally(!) getting some time again and will be helping out
Bill Tutt with svn_com wrappers around the SVN client API, so we can
start rolling more functionality into the UI.
Mark Murphy
mmurphy@collab.net
Re: How uniform can GUI clients be?
Posted by Daniel Stenberg <da...@haxx.se>.
On Tue, 30 Jan 2001, Joerg Bullmann wrote:
> So, to come to my point: how *uniform* can an SVN client be?
I totally agree that it might be hard to make really intuitive interfaces for
different platforms that are uniform and still match the paradigms and
peculiarities of those particular platforms.
Still, just guessing here, most platforms would probably use the same
approach and only the Mac would differ.
I would also like to point out that there doesn't have to be a single view.
Compare to the Clearcase GUI-viewer, in which you can select to display the
file tree in different ways, just as you can in most 'file explorer' type of
applications.
How people like to view things may not differ depending on what platform they
use, but on purely personal preferenses and ways of thinking.
> How should the SVN commands be represented? I'd suggest an "SVN" menu
> with entries for all SVN commands.
I'd say that there shouldn't be a need for a menu with "SVN commands".
There's a GUI and the "commands" should be replaced with GUI operations as
far as possible. Of course, allowing some commands and a shell prompt for
power users is still a feature that could be left in there but I'd prefer if
the GUI would not feel like just a fancy layer ontop of the SVN command line
commands. I'd want that a GUI-user shouldn't need nor have to know the SVN
client commands.
> Do we want a log window that shows all the server responses? I like it.
> But I think I recall someone (was it one of the Greg(g)s?) speaking out
> vehemently against it some time ago. My memory might fool me here.
I'm against it. Sure, it can *exist* if you select to enable it and if you
wanna do some under-the-surface debugging and see exactly what the server did
say. But I think that the GUI should present information and progress data to
prevent the need for a "server log".
Compare to when you copy files using your file browser on a GUI system, you
drap and drop the files and they are copied or moved with some indicator
showing that they are moved/copied. You do not get a window where all the
copy-lines are shown and you do not select a "command menu" where copy is
picked.
> A GUI SVN client could offer simple diff and conflict viewing features.
I'd say this is one of the areas where a GUI client can show its power. A
really fancy diff viewer in different colours or traces what was done between
versions. Things that are tricky on a shell prompt and gets easier/nicer
within a GUI.
> Hope my ideas can help here and spark off a bit of detail discussion. I'd
> love to meet up with people to talk through this in kind of a workshop,
Well, mailing back and forth is a pretty good start imho.
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
How uniform can GUI clients be? -- was: Re: Gui Clients
Posted by Joerg Bullmann <jo...@fontworks.com>.
Ben, Kevin, others
>that he'd rather have someone really sit down and *design* a single
>uniform gui across all platforms. I agreed that he made sense, and
Interesting thought. Let's have a look at how it is
in CVS. The fact that there are three (3 ! ;-) client
implementations for the Mac be left aside here, even
though this kind tells a story in itself, alas not a
juicy one [interested parties let me know ;-)].
But let's compare the Windows and Mac UI's. In windows,
you have a "direcory browser" on the left side and a file
list on the right side of the main CVS window.
For windows people this seems to make sense because this
folder browser file list combination is used in many
applications and people will therefore feel at home
immediately.
On the Mac, we don't have this. Instead, here traditionally,
you have combined folder/file views that show complete folder
structures in hierarchical lists. On the Mac this concept
originated in the finder list view sometime in Mac OS 7 and
people adopted it widely here.
Aside from the fact that this combined hierarchical list
view allows for selection of items in more than one folder
at the same time which does not seem easily possible in
Windows (I might be wrong here, please correct me), it is
the "natural" way people work and think on the Mac.
So, to come to my point: how *uniform* can an SVN client
be?
How should the SVN commands be represented? I'd suggest
an "SVN" menu with entries for all SVN commands. If people
select them, they could be presented with dialog boxes
where they can enter options via check boxes, popup menus,
etc. A toolbar could optionally be there.
The user's work space could be shown in a window with
a hierarchical file and folder list (Mac), a folder browser
file list combination (Win). This window would then show
the state of the files in the module (work space) so the
user easily sees what's going on (what's changed, what needs
check in, etc.). It could also allow access to cached file
logs or file diff output (stuff that has been received from
the server in a SVN diff or SVN log or some other command).
How should the work space window look on X/Motif/Gtk/Java/TCL
or so? Certainly I'd vote for the hierarchical file and
folder list like on the Mac ;-))). In MacCVSClient, I have
also implemented a "filter" option. With this you can
restrict the display to e.g. only locally modified files,
lost files, unknown files, files that had a diff when you
last ran a CVS diff -r version-1-0 -r version-1-1 or some
such. This is great because it often hides away thousands
of list entries so you can concentrate on those 23 files
that are of importance to you right now.
Do we want a log window that shows all the server responses?
I like it. But I think I recall someone (was it one of the
Greg(g)s?) speaking out vehemently against it some time ago.
My memory might fool me here.
A GUI SVN client could offer simple diff and conflict viewing
features.
What about file types and Mac OS resource fork handling?
>I'd like to recommend that *all* the volunteers interested
>in guis just sit down and start a real discussion about how
>the gui should look and feel.
May another one of those near-religious wars start. Or
rather not. 8-))
Hope my ideas can help here and spark off a bit of detail
discussion. I'd love to meet up with people to talk through
this in kind of a workshop, but I'm in Hong Kong and can't
really afford a ticket (snivel).
Joerg
Re: Gui Clients
Posted by Ben Collins-Sussman <su...@newton.collab.net>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> I was thinking of taking a stab at a Java gui, and maybe a Qt/KDE Gui
> too, (depending on how energetic I feel), but I was thinking it would be
> good if they all look fairly uniform, so does anyone have any screen
> shots of what the Windows Gui looks like? You could either mail them to
> me or post them on the web somewhere.
Careful here... you hit the nail on the head when you say that they
should all look "uniform".
A couple of folks have started working on a Win32 gui, already checked
into the tree, and I've also started a Gnome/GTK gui (not checked in
yet).
I stopped working on the GTK gui, however, because my boss pointed out
that he'd rather have someone really sit down and *design* a single
uniform gui across all platforms. I agreed that he made sense, and
that we probably attack the problem more carefully than the "look what
I hacked together last night" approach. :)
Of course, this *is* an open-source project, and therefore the only
*real* rule is, "if you write good code, people will use it." It sort
of contradicts the whole `quietly-planned-design' paradigm.
So I'm not trying to discourage you: if you have the time, go for it!
But I think my request is a general one toward the subversion
developer community: I'd like to recommend that *all* the volunteers
interested in guis just sit down and start a real discussion about how
the gui should look and feel. The few of us being paid to work on SVN
full-time obviously can't devote any real time to helping the gui
implementations (our priority is the core functionality now); but I'd
love to see the gui folks come together with a real,
honest-to-goodness UI spec -- one that's well thought out. My biggest
fear is a slew of fly-by-night guis that all behave differently. :)
Re: Gui Clients
Posted by "Matthew O. Persico" <pe...@acedsl.com>.
Kevin Pilch-Bisson wrote:
>
> On Tue, Jan 30, 2001 at 11:11:42PM +0100, Branko �ibej wrote:
> > Kevin Pilch-Bisson wrote:
> >
> > > Hey all,
> > >
> > > I was thinking of taking a stab at a Java gui, and maybe a Qt/KDE Gui
> > > too, (depending on how energetic I feel), but I was thinking it would be
> > > good if they all look fairly uniform, so does anyone have any screen
> > > shots of what the Windows Gui looks like? You could either mail them to
> > > me or post them on the web somewhere.
> >
> > What happened to your versionable filesystem? :-)
>
> Its still kicking around as an idea. I just want to get more familiar
> with the subversion stuff before I start out.
Hmm, versionable file system. Sounds like ClearCase to me... :-)
But seriously, I think CC has the best paradigm in SCM. Unfortuntely, it
is way too wieldy (read: expensive) for my situation.
However, once SVN is up and stable, how far would we really be from
implementing the CC paradigm?
Of course, the other question is, how many patents are violated in the
attempt?
Food for thought...
--
Matthew O. Persico
"If you were supposed to understand it,
we wouldn't call it code." - FedEx
Shop online without a credit card
http://www.rocketcash.com
RocketCash, a NetZero subsidiary
Re: Subversion vs. filesystems
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> That is indeed an interesting idea. An immediate problem is how are
> files added to the repository automatically, or with a command. If
> automatically, then it would need a good way to know what not to include
> automatically. If with a command then there can still be the problem of
> forgetting to add things.
Yep. There are a lot of hairy questions here. But I think it would
be something cool to play with.
Re: Subversion vs. filesystems
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Thu, Feb 01, 2001 at 04:28:33PM -0500, Jim Blandy wrote:
>
> Kevin, you're the fellow who was talking about implementing a genuine
> mountable filesystem that tracked versions, right? What I think would
> be really useful along those lines would be to implement a filesystem
> on top of the *client* library --- you'd get a working directory where
> ordinary "rm", "mv", and "cp" would maintain the meta-information
> Subversion needs to do commits and updates. You could just use Emacs
> dired to mess around in your working copy, and it'd all Just Work.
That is indeed an interesting idea. An immediate problem is how are
files added to the repository automatically, or with a command. If
automatically, then it would need a good way to know what not to include
automatically. If with a command then there can still be the problem of
forgetting to add things.
>
> Detecting copies is a bit of a challenge, but I think GNU cp is a
> "memory mapped" cp: it maps the entire input file into memory, and
> then does a single write request to create the new file. This means
> that the write uses the exact same pages as the read. Perhaps the
> filesystem could notice which file the pages were coming from,
> recognize that a copy was in progress, and adjust the Subversion
> metainformation appropriately.
I think I am still some time away from actually starting to implement
something, but thanks for the technical help. I'm sure it will come in
handy.
--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
http://www.pilch-bisson.net
PGP Public Key At http://pgp.pilch-bisson.net
Re: Subversion vs. filesystems
Posted by Branko Čibej <br...@xbc.nu>.
Matthew O. Persico wrote:
> Before you go off and work to hard to re-invent the wheel, maybe you can
> get some good ideas from the ClearCase site and its white papers. After
> all, if I read this correctly, an "installable version-tracking
> filesystem" smells a LOT like ClearCase to me. And I LOVED ClearCase,
> but I had to leave it behind when I changed jobs three years ago. Sigh.
Heh. I use ClearCase at work. But that's just incidental -- I helped
design and write such a filesystem for another configuration management
tool. So no, I'm not about to reinvent the wheel, I'm just gonna copy
it. :-)
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: Subversion vs. filesystems
Posted by "Matthew O. Persico" <pe...@acedsl.com>.
Branko �ibej wrote:
>
> Jim Blandy wrote:
>
> > Kevin, you're the fellow who was talking about implementing a genuine
> > mountable filesystem that tracked versions, right? What I think would
> > be really useful along those lines would be to implement a filesystem
> > on top of the *client* library --- you'd get a working directory where
> > ordinary "rm", "mv", and "cp" would maintain the meta-information
> > Subversion needs to do commits and updates. You could just use Emacs
> > dired to mess around in your working copy, and it'd all Just Work.
>
> That's the logical way to do it, so that you're not limited to mounting
> only from a local directory.
>
> > Detecting copies is a bit of a challenge, but I think GNU cp is a
> > "memory mapped" cp: it maps the entire input file into memory, and
> > then does a single write request to create the new file. This means
> > that the write uses the exact same pages as the read. Perhaps the
> > filesystem could notice which file the pages were coming from,
> > recognize that a copy was in progress, and adjust the Subversion
> > metainformation appropriately.
>
> This would depend on having GNU cp too much. One of the ways to solve
> this problem is to simply not have automatic commits, or at least
> require an explicit "register" command for new files -- the ancestor
> file could be passed as an argument.
>
> I'd advise against trying to be too smart about detecting copies. From
> my experience it creates more problems than it solves. For instance, you
> can't distinguish between a "real" copy and a tool creating a backup
> file; and you don't want to put backup files in the repository. A
> .cvsignore-ish approach will work, but then you've just moved the magic
> from a command to a filter -- which is almost certain to bite you someday.
>
> It would be nice to have such a filesystem be completely transparent,
> but in practice you'll use extra revision control commands anyway, or
> you wouldn't need a versioning filesystem.
>
Before you go off and work to hard to re-invent the wheel, maybe you can
get some good ideas from the ClearCase site and its white papers. After
all, if I read this correctly, an "installable version-tracking
filesystem" smells a LOT like ClearCase to me. And I LOVED ClearCase,
but I had to leave it behind when I changed jobs three years ago. Sigh.
> --
> Brane �ibej
> home: <br...@xbc.nu> http://www.xbc.nu/brane/
> work: <br...@hermes.si> http://www.hermes-softlab.com/
> ACM: <br...@acm.org> http://www.acm.org/
--
Matthew O. Persico
"If you were supposed to understand it,
we wouldn't call it code." - FedEx
Shop online without a credit card
http://www.rocketcash.com
RocketCash, a NetZero subsidiary
Re: Subversion vs. filesystems
Posted by Branko Čibej <br...@xbc.nu>.
Jim Blandy wrote:
> Kevin, you're the fellow who was talking about implementing a genuine
> mountable filesystem that tracked versions, right? What I think would
> be really useful along those lines would be to implement a filesystem
> on top of the *client* library --- you'd get a working directory where
> ordinary "rm", "mv", and "cp" would maintain the meta-information
> Subversion needs to do commits and updates. You could just use Emacs
> dired to mess around in your working copy, and it'd all Just Work.
That's the logical way to do it, so that you're not limited to mounting
only from a local directory.
> Detecting copies is a bit of a challenge, but I think GNU cp is a
> "memory mapped" cp: it maps the entire input file into memory, and
> then does a single write request to create the new file. This means
> that the write uses the exact same pages as the read. Perhaps the
> filesystem could notice which file the pages were coming from,
> recognize that a copy was in progress, and adjust the Subversion
> metainformation appropriately.
This would depend on having GNU cp too much. One of the ways to solve
this problem is to simply not have automatic commits, or at least
require an explicit "register" command for new files -- the ancestor
file could be passed as an argument.
I'd advise against trying to be too smart about detecting copies. From
my experience it creates more problems than it solves. For instance, you
can't distinguish between a "real" copy and a tool creating a backup
file; and you don't want to put backup files in the repository. A
.cvsignore-ish approach will work, but then you've just moved the magic
from a command to a filter -- which is almost certain to bite you someday.
It would be nice to have such a filesystem be completely transparent,
but in practice you'll use extra revision control commands anyway, or
you wouldn't need a versioning filesystem.
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: Subversion vs. filesystems
Posted by Bob Miller <kb...@jogger-egg.com>.
Jim Blandy wrote:
> Detecting copies is a bit of a challenge
Compare the new file's md5 sum with those of existing files.
(As a special case, all empty files aren't equal. (-: )
--
K<bob>
kbob@jogger-egg.com, http://www.jogger-egg.com/
Subversion vs. filesystems
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
Kevin, you're the fellow who was talking about implementing a genuine
mountable filesystem that tracked versions, right? What I think would
be really useful along those lines would be to implement a filesystem
on top of the *client* library --- you'd get a working directory where
ordinary "rm", "mv", and "cp" would maintain the meta-information
Subversion needs to do commits and updates. You could just use Emacs
dired to mess around in your working copy, and it'd all Just Work.
Detecting copies is a bit of a challenge, but I think GNU cp is a
"memory mapped" cp: it maps the entire input file into memory, and
then does a single write request to create the new file. This means
that the write uses the exact same pages as the read. Perhaps the
filesystem could notice which file the pages were coming from,
recognize that a copy was in progress, and adjust the Subversion
metainformation appropriately.
Re: Gui Clients
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Tue, Jan 30, 2001 at 11:11:42PM +0100, Branko Èibej wrote:
> Kevin Pilch-Bisson wrote:
>
> > Hey all,
> >
> > I was thinking of taking a stab at a Java gui, and maybe a Qt/KDE Gui
> > too, (depending on how energetic I feel), but I was thinking it would be
> > good if they all look fairly uniform, so does anyone have any screen
> > shots of what the Windows Gui looks like? You could either mail them to
> > me or post them on the web somewhere.
>
> What happened to your versionable filesystem? :-)
Its still kicking around as an idea. I just want to get more familiar
with the subversion stuff before I start out.
>
> --
> Brane Èibej
> home: <br...@xbc.nu> http://www.xbc.nu/brane/
> work: <br...@hermes.si> http://www.hermes-softlab.com/
> ACM: <br...@acm.org> http://www.acm.org/
>
>
--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
http://www.pilch-bisson.net
PGP Public Key At http://pgp.pilch-bisson.net
Re: Gui Clients
Posted by Branko Čibej <br...@xbc.nu>.
Kevin Pilch-Bisson wrote:
> Hey all,
>
> I was thinking of taking a stab at a Java gui, and maybe a Qt/KDE Gui
> too, (depending on how energetic I feel), but I was thinking it would be
> good if they all look fairly uniform, so does anyone have any screen
> shots of what the Windows Gui looks like? You could either mail them to
> me or post them on the web somewhere.
What happened to your versionable filesystem? :-)
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/