Re: [viewvc-users] Error due to filename with accented character while building/updating a commit database using cvsdbadmin

"C. Michael Pilato" <[email protected]>
Newsgroups gmane.comp.version-control.cvs.viewcvs.user
Organization CollabNet, Inc.
Message-ID <[email protected]>
On 11/18/2010 06:27 AM, [email protected] wrote:
> I am trying to build a commit database on a Windows 2003 SP2 server, 
> ActiveState Python 2.5, Cvsnt 2.5.05.3744, ViewVC 1.1.5 I get this 
> error when ViewVC processes a file with an accentd character in its 
> name:
> 
> [sources/IK-STAT/doc/src/Funzionalit ikstat.doc [2 new 
> commits]]Traceback (most
> recent call last):
>   File "cvsdbadmin", line 191, in <module>
>     command == 'update', quiet_level)
>   File "cvsdbadmin", line 88, in RecurseUpdate
>     RecurseUpdate(db, repository, path, update, quiet_level)
>   File "cvsdbadmin", line 88, in RecurseUpdate
>     RecurseUpdate(db, repository, path, update, quiet_level)
>   File "cvsdbadmin", line 88, in RecurseUpdate
>     RecurseUpdate(db, repository, path, update, quiet_level)
>   File "cvsdbadmin", line 92, in RecurseUpdate
>     UpdateFile(db, repository, path, update, quiet_level)
>   File "cvsdbadmin", line 64, in UpdateFile
>     print '[%s [%d new commits]]' % (file, len(commit_list)),
> IOError: [Errno 0] Error
> 
> 
> The actual file name is "sources/IK-STAT/doc/src/Funzionalità 
> ikstat.doc", with an accented a letter. ViewVC displays a related error 
> when I try to access the directory in which the file resides:
> 
> Traceback (most recent call last):
>   File "c:\programmi\viewvc\lib\viewvc.py", line 4317, in main
>     request.run_viewvc()
>   File "c:\programmi\viewvc\lib\viewvc.py", line 397, in run_viewvc
>     self.view_func(self)
>   File "c:\programmi\viewvc\lib\viewvc.py", line 1909, in 
> view_directory
>     file_data, options)
>   File "c:\programmi\viewvc\lib\vclib\ccvs\bincvs.py", line 247, in 
> dirlogs
>     alltags = _get_logs(self, path_parts, entries_to_fetch, rev, 
> subdirs)
>   File "c:\programmi\viewvc\lib\vclib\ccvs\bincvs.py", line 1017, in 
> _get_logs
>     ', found %s' % (file and file.path, filename))
> Error: Error parsing rlog output. Expected RCS file 
> E:\Repository\digint\sources\IK-STAT\doc\src\Funzionalit� ikstat.doc,v, 
> found E:\Repository\digint\sources\IK-STAT\doc\src\Funzionalità 
> ikstat.doc,v
> 
> The "expected file" shows a square symbol instead of the accented a, 
> while the "found file" is correct. If I switch the browser enconding 
> (IE8) from UTF-8 to Windows West Europe (I guess it's Windows 1252), 
> the "expected" file is shown correctly while the "found" one is shown 
> with a different character for the accented a. Thereby I believe there 
> are some codepage issues between ViewVC, rlog.exe and filenames under 
> Windows.
> 
> Is this fixed in a later release? Or is it an open issue?

This may be another manifestation of the general problem reported in
http://viewvc.tigris.org/issues/show_bug.cgi?id=292, which is effectively
that MySQL isn't being used in any sort of i18n-friendly fashion.
Complicating this for CVS repositories is that CVS is locale-agnostic
(locale-ignorant?)  There's no way to reliably figure out what character
encoding is in use for the paths in your CVS repositories, log messages,
etc.  (Which makes normalization to, say, UTF-8 for use in the MySQL
database rather difficult.)

-- 
C. Michael Pilato <[email protected]>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

------------------------------------------------------
http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4255&dsMessageId=2682768

To unsubscribe from this discussion, e-mail: [[email protected]].
signature.asc (application/pgp-signature, 198 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkzlPnUACgkQokEGqRcG/W4zsACgmhQMT16xWTnjAMDeZm5HSoID
Fd0AoML5BsgIBI3Y4Ybc0glAU36R3GV0
=OYH3
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.