On Jun 13, 2007, at 09:30, Giulio Troccoli wrote:
>> If I'm understanding you properly, your issue boils down to the
>> following:
>>
>> "If nothing is reported back to the user, the user doesn't understand
>> that nothing was done."
>>
>> Is that a fair assessment?
>
> Yes it is, although I would phrase it more like "I personally can't
> bare
> the thought of users complaining that Subversion didn't tell them that
> nothing was actually committed and I want to do something about it
> before that happens"
I think the only thing for you to do at this point is to educate your
users. You can give your users a GUI too, but they will still need to
understand the basic Subversion principles, so there's no substitute
for a little training class, or making each of them read the
Subversion book.
If they are running "svn commit" and are surprised that nothing got
committed, then a failure has already occurred: it should be standard
operating procedure for every developer to run "svn status" and "svn
diff" before every commit, to see what would be committed. Both of
those commands would return empty if there's nothing to commit, so if
they were using Subversion properly they would already have
discovered that "svn commit" would do nothing.
It is important to get in the habit of checking what will be
committed, before committing it, so that an accurate log message can
be written at commit time, and so that unintended changes are not
accidentally committed. If you just commit without looking first what
you're committing, you're going to end up with crap in your
repository. Suppose a developer is working on an experimental feature
Friday evening, breaking various parts of the code to see what
happens, adding lots of debugging statements, etc. He doesn't finish
with his experiments by the time he leaves the office, and over the
weekend he forgets all about it. On Monday he needs to fix a bug in
the software -- maybe even a simple typo where he already knows his
change is correct without needing to run the software to test -- and
he goes to his working copy, fixes the mistake, and commits, noting
in the log message "fixing typo in foobar". Depending on where he
committed from, he may now have also transmitted some or all of his
unfinished broken experiments from Friday. The output from "svn
commit" might alert him to the fact that something's up, if more
files are displayed as being transmitted to the repository than he
expected. But even if it does, that's not a good time to notice the
mistake. The time to notice it is before committing, by using "svn
status" and "svn diff" to ensure that the changes you're about to
commit are in fact the changes you want to commit.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 13 20:40:34 2007