On Wed, Jan 26, 2005 at 07:31:34PM +1100, matthew ford wrote:
> What I am trying to convey is that the software is ment to serve the user
> (not the other way round).
> No one likes to think of themselves as wrong or dumb, so the initial
> response to a software problem is "Its the software's fault" I asked it to
> do X and it did Y. I know want I want to do. Why will the software not do
> it for me? The packet said this was ABC software so I should be able to do
> X.
But sometimes users are actually wrong. And if you fail to read the
accompanying documentation chances are severe that you are indeed
wrong, no matter if you like to think of yourself that way. If you want
to use a complex tool like Subversion you have to understand what it
does and the only way to do this is to read (and understand) the docs.
That you think you can do X is not a problem with the software, it's a
problem with you not reading the documentation which says you cannot do
X.
> Now if the software cannot do X, this needs to be clearly and
> courteously conveyed to the user. Good software tries to maintian the
> dignity of the user, not pull them down or show them up.
So Subversion should in some manner tell every user what they cannot do
by guessing what they're trying to do? Software just doesn't have that
kind of intelligence, though we all would like to see it implemented.
If you have any concrete suggestions for improvement I'm sure they'll be
seriously considered.
> Obviously what the user expects from the software depends on the
> user's past experiences. Which is why it is important to know who
> your users are and what their background is.
And most users of Subversion are developers. And most developers know
diff as it's a standard way of telling the difference between two files.
If not, it's not too hard to research the subject yourself.
> As I mentioned in another posting, a good working knowledge of diff
> appears to be a pre-requesite for using merge correctly. But not all
> the users coming to subversion have a good working knowledge of diff.
> I have suggested this be adressed in some way in the documentation
> since subversion appears to be too far down the track to change the
> existing CLI merge to accomodate these users. (Perhaps 'smart merge'
> can address this.)
The documentation on merge says:
It's time to use the svn merge command. This command, it turns
out, is a very close cousin to the svn diff command (which you
read about in Chapter 3).
Now chapter 3[1] says:
...which prints out file changes in unified diff format.
If you do not know what unified diff format is this might be a good time
to visit Google. The first hit on "unified diff format" is the GNU
manual on the unified format[2]. If you still do not understand diff and
patch a reasonable question would be: "I don't understand diff and
patch, could somebody explain this to me?".
You may think it is unreasonable to expect a certain level of knowledge.
In my opinion, the Subversion documentation should describe Subversion
and not whatever else which is already described (better) elsewhere.
Oh and BTW, you have a bad habit of starting new threads instead of
following up on the current. I just counted 6 new posts on the current
subject. Please stick to one thread as this makes it much easier to
locate the posts in the users archive[3].
[1]: <http://svnbook.red-bean.com/en/1.1/ch03s05.html#svn-ch-3-sect-5.3.2>
[2]: <http://www.gnu.org/software/diffutils/manual/html_node/Unified-Format.html>
[3]: <http://svn.haxx.se/users/archive-2005-01/>
--
Cheers,
- Jacob Atzen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 26 11:13:42 2005