You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Lübbe Onken <l....@rac.de> on 2005/05/02 15:45:25 UTC
Error message nitpick
Hi Folks,
we have got several error messages concerning the working copy that use
the term 'locked' but have nothing to do with locking files.
From the po file:
'Working copy not locked; this is probably a bug, please report'
I also remember seeing (haven't found in current po file, so probably
obsolete)
'Working copy locked, please run cleanup'
I think that these cases of using 'locked' will confuse users.
Cheers
- Lübbe
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error message nitpick
Posted by Julian Foad <ju...@btopenworld.com>.
Peter McNab wrote:
> Lübbe Onken wrote:
>> Eventually the last two examples could be resolved by using the
>> "intended function" as prefix:
>> "SVN WC: Working copy not locked; this is probably a bug, please report"
>> "Locking: Attempt to unlock with non-empty unwind stack"
>
> A very good practice, where you don't mind exposing the inner workings
> and this being open source has nothing to hide.
> Such prefixing really helps developers.
Developers don't need such help, as they already get told the source file name
an line number (this information is enabled by the configure option
"--enable-maintainer-mode"), and they can search in the source for the message
text.
We are trying to make error messages meaningful for end-users.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error message nitpick
Posted by Peter McNab <mc...@melbpc.org.au>.
Lübbe Onken wrote:
> Ben Collins-Sussman wrote:
>
>
>> Those errors are as old as svn itself. The problem is that we now
>> have four definitions of 'lock':
>
>
> I remember :-)
>
>> * working-copy 'locks', used to get exclusive access to a working
>> copy dir (used by libsvn_wc),
>>
>> * repository BDB 'locks', a resource that BDB can run out of,
>>
>> * repository FSFS 'write lock', used by libsvn_fs_fs to get
>> exclusive access when doing a write operation,
>>
>> * repository locks -- the new svn 1.2 feature for reserving access
>> to imaginary files.
>>
>>
>> I'm not sure what we can do to disambiguate these error messages or
>> terminologies.
>
>
> I just did a quick grep for "lock" on the subversion.pot file which
> results in 95 matches. Most of them have to do with the locking
> functionality.
>
> I have no idea how to resolve this completely, here are some randomly
> picked messages and a partial solution:
>
> "Error opening db lockfile"
> => db = server != working copy => Locking UI not involved => OK
>
> "Can't get exclusive lock on file '%s'"
> => I wasn't locking this file was I? => Confused
>
> "Can't unlock charset translation mutex"
> => sounds so far away, can't have anything to do with locking :-)
>
> "Cannot write lock/entries hashfile '%s'"
> => Did I get my lock now or didn't I?
>
> "Working copy not locked; this is probably a bug, please report"
> => It's probably a bug, but is my file locked now or not?
>
> "Attempt to unlock with non-empty unwind stack"
> => Huh?
>
> For a partial solution I'd suggest to prefix error messages with the
> module that's throwing them.
>
> Examples, used the filename as a hint for the prefix:
> "BDB: Error opening db lockfile"
> "FileIO: Can't get exclusive lock on file"
> "UTF: Can't unlock charset translation mutex"
> "FSFS: Cannot write lock/entries hashfile '%s'"
> "SVN Error: Working copy not locked; this is probably a bug, please
> report"
> "SVN Error: Attempt to unlock with non-empty unwind stack"
>
> this would get rid of at least some of the ambiguities.
>
> Eventually the last two examples could be resolved by using the
> "intended function" as prefix:
> "SVN WC: Working copy not locked; this is probably a bug, please report"
> "Locking: Attempt to unlock with non-empty unwind stack"
>
> Cheers
> -Lübbe
A very good practice, where you don't mind exposing the inner workings
and this being open source has nothing to hide.
Such prefixing really helps developers.
Peter,
a lurker-developer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error message nitpick
Posted by Lübbe Onken <lu...@tigris.org>.
Ben Collins-Sussman wrote:
> Those errors are as old as svn itself. The problem is that we now have
> four definitions of 'lock':
I remember :-)
> * working-copy 'locks', used to get exclusive access to a working copy
> dir (used by libsvn_wc),
>
> * repository BDB 'locks', a resource that BDB can run out of,
>
> * repository FSFS 'write lock', used by libsvn_fs_fs to get exclusive
> access when doing a write operation,
>
> * repository locks -- the new svn 1.2 feature for reserving access to
> imaginary files.
>
>
> I'm not sure what we can do to disambiguate these error messages or
> terminologies.
I just did a quick grep for "lock" on the subversion.pot file which
results in 95 matches. Most of them have to do with the locking
functionality.
I have no idea how to resolve this completely, here are some randomly
picked messages and a partial solution:
"Error opening db lockfile"
=> db = server != working copy => Locking UI not involved => OK
"Can't get exclusive lock on file '%s'"
=> I wasn't locking this file was I? => Confused
"Can't unlock charset translation mutex"
=> sounds so far away, can't have anything to do with locking :-)
"Cannot write lock/entries hashfile '%s'"
=> Did I get my lock now or didn't I?
"Working copy not locked; this is probably a bug, please report"
=> It's probably a bug, but is my file locked now or not?
"Attempt to unlock with non-empty unwind stack"
=> Huh?
For a partial solution I'd suggest to prefix error messages with the
module that's throwing them.
Examples, used the filename as a hint for the prefix:
"BDB: Error opening db lockfile"
"FileIO: Can't get exclusive lock on file"
"UTF: Can't unlock charset translation mutex"
"FSFS: Cannot write lock/entries hashfile '%s'"
"SVN Error: Working copy not locked; this is probably a bug, please report"
"SVN Error: Attempt to unlock with non-empty unwind stack"
this would get rid of at least some of the ambiguities.
Eventually the last two examples could be resolved by using the
"intended function" as prefix:
"SVN WC: Working copy not locked; this is probably a bug, please report"
"Locking: Attempt to unlock with non-empty unwind stack"
Cheers
-Lübbe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Error message nitpick
Posted by Ben Collins-Sussman <su...@collab.net>.
On May 2, 2005, at 10:45 AM, Lübbe Onken wrote:
> Hi Folks,
>
> we have got several error messages concerning the working copy that
> use the term 'locked' but have nothing to do with locking files.
>
> From the po file:
> 'Working copy not locked; this is probably a bug, please report'
>
> I also remember seeing (haven't found in current po file, so probably
> obsolete)
> 'Working copy locked, please run cleanup'
>
> I think that these cases of using 'locked' will confuse users.
>
Those errors are as old as svn itself. The problem is that we now have
four definitions of 'lock':
* working-copy 'locks', used to get exclusive access to a working
copy dir (used by libsvn_wc),
* repository BDB 'locks', a resource that BDB can run out of,
* repository FSFS 'write lock', used by libsvn_fs_fs to get exclusive
access when doing a write operation,
* repository locks -- the new svn 1.2 feature for reserving access to
imaginary files.
I'm not sure what we can do to disambiguate these error messages or
terminologies.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: The word "lock" in error messages and help [was: Error message
nitpick]
Posted by Lübbe Onken <lu...@tigris.org>.
Julian Foad wrote:
> Could you please file an issue for this?
Issue #2303
Cheers
- Lübbe
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
The word "lock" in error messages and help [was: Error message nitpick]
Posted by Julian Foad <ju...@btopenworld.com>.
Lübbe Onken wrote:
> we have got several error messages concerning the working copy that use
> the term 'locked' but have nothing to do with locking files.
>
> From the po file:
> 'Working copy not locked; this is probably a bug, please report'
[...]
> I think that these cases of using 'locked' will confuse users.
Also the help text in subversion/clients/cmdline/main.c (displayed by "svn help
SUBCOMMAND") suffers from the same problem: e.g. "svn help cleanup" says
"removing locks".
Could you please file an issue for this?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org