You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Malcolm Rowe <ma...@farside.org.uk> on 2005/10/27 12:48:06 UTC
ViewCVS broken for r17006
Does the fact that ViewCVS on svn.collab.net is throwing an exception
for r17006 indicate that there's anything wrong with the SVN repository
itself, or is it just a bug in ViewCVS?
http://svn.collab.net/viewcvs/svn?rev=17006&view=rev
It looks like it might be complaining about the content of the svn:date
revprop on that revision, though I can't see anything wrong with it via
DAV (I assume ViewCVS uses ra_local, though).
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ViewCVS broken for r17006
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Oct 28, 2005 at 09:28:56AM -0400, C. Michael Pilato wrote:
> Martin Tomes <li...@tomes.org> writes:
>
> > I have installed the trunk ViewCVS (as of last weekend) on a freshly
> > installed Fedora Core 4 with the Subversion RPMS and viewing a
> > revision:
> >
> > /viewcvs.cgi?rev=661&view=rev
> >
> > Gives this error:
> >
> > An Exception Has Occurred
> > Python Traceback
>
> [...]
>
> > SubversionException: (None, 125003)
> >
> > Is this related or do I have a different problem?
>
> Looks like a bad date of some sort:
>
> [subversion] $ tools/dev/which-error.py 125003
> 00125003 SVN_ERR_BAD_DATE
>
> Not enough information in your email to verify/debug that, but the
> error code is clear.
A friend of mine emailed me privately with the exact same error message
earlier this week.
I haven't had a chance to look into it, but if someone else is seeing it
too, I think it mean something's busted with our Python bindings and
ViewCVS somehow. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ViewCVS broken for r17006
Posted by "C. Michael Pilato" <cm...@collab.net>.
Martin Tomes <li...@tomes.org> writes:
> I have installed the trunk ViewCVS (as of last weekend) on a freshly
> installed Fedora Core 4 with the Subversion RPMS and viewing a
> revision:
>
> /viewcvs.cgi?rev=661&view=rev
>
> Gives this error:
>
> An Exception Has Occurred
> Python Traceback
[...]
> SubversionException: (None, 125003)
>
> Is this related or do I have a different problem?
Looks like a bad date of some sort:
[subversion] $ tools/dev/which-error.py 125003
00125003 SVN_ERR_BAD_DATE
Not enough information in your email to verify/debug that, but the
error code is clear.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ViewCVS broken for r17006
Posted by Martin Tomes <li...@tomes.org>.
I have installed the trunk ViewCVS (as of last weekend) on a freshly
installed Fedora Core 4 with the Subversion RPMS and viewing a revision:
/viewcvs.cgi?rev=661&view=rev
Gives this error:
An Exception Has Occurred
Python Traceback
Traceback (most recent call last):
File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 3362, in main
request.run_viewcvs()
File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 379, in
run_viewcvs
self.view_func(self)
File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 2800, in
view_revision
date, author, msg, changes = vclib.svn.get_revision_info(request.repos)
File "/usr/local/viewcvs-1.0-dev/lib/vclib/svn/__init__.py", line
255, in get_revision_info
svnrepos.pool)
File "/usr/local/viewcvs-1.0-dev/lib/vclib/svn/__init__.py", line 93,
in _datestr_to_date
return core.svn_time_from_cstring(datestr, pool) / 1000000
SubversionException: (None, 125003)
Is this related or do I have a different problem?
--
Martin Tomes
echo 'martin at tomes x org x uk'\
| sed -e 's/ x /\./g' -e 's/ at /@/'
Visit http://www.subversionary.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ViewCVS broken for r17006
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Fri, Oct 28, 2005 at 09:25:57AM -0400, C. Michael Pilato wrote:
> > The '--strict' option just prevents the terminating newline from being
> > output by the client, nothing else.
>
> It better do more than that, because I added it (in r5424) to support
> byte-for-byte output of binary property values. It was touched up
> later (r14505) to not print a trailing newline when used on revprops.
>
No, actually, that _is_ all it does. The binary property stuff you added
in r5424 is done unconditionally. Oh, all right: it also suppresses
filenames in multi-target propgets.
> But yeah, as you noted, our svn: props get munged and translated and
> stuff, so the --strict output isn't so strict after all for those
> properties.
>
Sure. And so as a result, we can't be sure we've got the original property
value. Would it maybe make sense to disable the translation completely
when --strict is used?
> > Because _that_ revision was committed by the EBCDIC guys, and I'm
> > immediately suspicious of anything their weird non-ASCII clients might be
> > doing?
>
> Ah, I didn't make that connection. Interesting...
>
Unfortunately, I don't think it bears up (and I _was_ kidding; hope
I made that clear) - there are a number of other commits from those
clients that don't have this problem.
No, I think this is going to actually require someone to look at what
the Python binding are returning on the server.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ViewCVS broken for r17006
Posted by Mark Phippard <ma...@softlanding.com>.
Philip Martin <ph...@codematters.co.uk> wrote on 10/28/2005 10:26:01 AM:
> Once it's available I think it's perfectly acceptable for you to use a
> EBCDIC client, if that's what you want to do. The server is supposed
> to work with any client that follows the protocol.
We have no great desire to use an EBCDIC client. We just want to
reasonably thorough in our port and quite a few users have asked for this.
It is also good for scripting. For example, I might have a web server
hosted on OS/400, and I want to run "svn up" on a nightly basis to pull in
the latest changes from the repository.
I am not sure if we will ever try to port ra_dav to OS/400, as that would
mean we have to also potentially port Neon and OpenSSL. But we have
ra_local and ra_svn working reasonably well. Our big problem now is
porting the test suite. There isn't an offical version of Python
available for OS/400 so running the tests is a challenge with the port
that is available. With the server port the testing was easier, because
we could run the tests from a Windows client against our OS/400 server.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ViewCVS broken for r17006
Posted by Philip Martin <ph...@codematters.co.uk>.
Mark Phippard <ma...@softlanding.com> writes:
> cmpilato@localhost.localdomain wrote on 10/28/2005 09:25:57 AM:
>
>> > Because _that_ revision was committed by the EBCDIC guys, and I'm
>> > immediately suspicious of anything their weird non-ASCII clients might
> be
>> > doing?
>>
>> Ah, I didn't make that connection. Interesting...
>
> The EBCDIC port is just a server. We do not have an EBCDIC client, (yet)
> and we certainly are not using it to commit to your repository.
Once it's available I think it's perfectly acceptable for you to use a
EBCDIC client, if that's what you want to do. The server is supposed
to work with any client that follows the protocol.
As for the current problem, I'm not sure the client has any influence
since svn:date is generated by the server during the commit. A client
could subsequently change svn:date, but I can see no propchange email
so that doesn't appear to have happened.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ViewCVS broken for r17006
Posted by Mark Phippard <ma...@softlanding.com>.
cmpilato@localhost.localdomain wrote on 10/28/2005 09:25:57 AM:
> > Because _that_ revision was committed by the EBCDIC guys, and I'm
> > immediately suspicious of anything their weird non-ASCII clients might
be
> > doing?
>
> Ah, I didn't make that connection. Interesting...
The EBCDIC port is just a server. We do not have an EBCDIC client, (yet)
and we certainly are not using it to commit to your repository. We do
almost everything with TortoiseSVN, although I may have done a couple of
commits using Subclipse (via JavaHL). I think I have also done a couple
from OS X using the regular CLI.
Mark
PS - The EBCDIC port is about working correctly on a system where EBCDIC
is the default locale. We still run Subversion in ASCII/UTF-8 mode on the
EBCDIC system.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ViewCVS broken for r17006
Posted by "C. Michael Pilato" <cm...@collab.net>.
Malcolm Rowe <ma...@farside.org.uk> writes:
> > Yeah, I thought this might be the possibility, but 'svn pget --strict'
> > reveals no trailing NUL.
>
> The '--strict' option just prevents the terminating newline from being
> output by the client, nothing else.
It better do more than that, because I added it (in r5424) to support
byte-for-byte output of binary property values. It was touched up
later (r14505) to not print a trailing newline when used on revprops.
But yeah, as you noted, our svn: props get munged and translated and
stuff, so the --strict output isn't so strict after all for those
properties.
> > (And besides, why would we suddenly start
> > seeing trailing NULs in one revision's datestamp and not others?)
>
> Because _that_ revision was committed by the EBCDIC guys, and I'm
> immediately suspicious of anything their weird non-ASCII clients might be
> doing?
Ah, I didn't make that connection. Interesting...
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ViewCVS broken for r17006
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Thu, Oct 27, 2005 at 11:29:05AM -0400, C. Michael Pilato wrote:
> > svn_string_t (which svn_fs_txn_prop() [et al] uses) are counted strings.
> > I wondered if this is due to the difference between a property containing
> > "2005-10-25T14:52:07.936032Z" (r17005) and one containing something like
> > "2005-10-25T15:33:29.047905Z\0" (r17006). Of course, I've no way to
> > test that theory, since for all I know, ra_dav strips out everything
> > following a NUL byte.
>
> Yeah, I thought this might be the possibility, but 'svn pget --strict'
> reveals no trailing NUL.
The '--strict' option just prevents the terminating newline from being
output by the client, nothing else.
In any case, any NUL characters in the property value _would_ be stripped
out, since svn_cl__propget() calls svn_subst_detranslate_string()
to convert the property contents to local EOL style and code page
[because it's an 'svn:' property, and those properties are assumed
to be in UTF-8 with NL line-terminators] - and _that_ procedure
would be better named svn_subst_detranslate_cstring(), since it calls
svn_subst_translate_cstring2() to do the actual translation, stripping
out anything following a NUL.
> (And besides, why would we suddenly start
> seeing trailing NULs in one revision's datestamp and not others?)
Because _that_ revision was committed by the EBCDIC guys, and I'm
immediately suspicious of anything their weird non-ASCII clients might be
doing?
Just kidding. I've no idea why this particular revision might be
causing trouble; the embedded NUL byte idea above is based solely on the
(truncated) message coming out of ViewCVS - "svn_time_from_cstring()
argument 1 must be string without null bytes, not str...".
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ViewCVS broken for r17006
Posted by "C. Michael Pilato" <cm...@collab.net>.
Malcolm Rowe <ma...@farside.org.uk> writes:
> On Thu, Oct 27, 2005 at 09:29:18AM -0400, C. Michael Pilato wrote:
> > > It looks like it might be complaining about the content of the svn:date
> > > revprop on that revision, though I can't see anything wrong with it via
> > > DAV (I assume ViewCVS uses ra_local, though).
> >
> > ViewCVS uses direct repository access via the Subversion Python
> > bindings (but *can* use any of the three RA layers, too, at the cost
> > of years of your life waiting for responses).
> >
> > But yeesh -- I can't see anything wrong with that date, either.
> > Weirdness. Guess I've some debugging to do today... Thanks for
> > pointing this out, Malcolm!
> >
>
> svn_string_t (which svn_fs_txn_prop() [et al] uses) are counted strings.
> I wondered if this is due to the difference between a property containing
> "2005-10-25T14:52:07.936032Z" (r17005) and one containing something like
> "2005-10-25T15:33:29.047905Z\0" (r17006). Of course, I've no way to
> test that theory, since for all I know, ra_dav strips out everything
> following a NUL byte.
Yeah, I thought this might be the possibility, but 'svn pget --strict'
reveals no trailing NUL. (And besides, why would we suddenly start
seeing trailing NULs in one revision's datestamp and not others?)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ViewCVS broken for r17006
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Thu, Oct 27, 2005 at 09:29:18AM -0400, C. Michael Pilato wrote:
> > It looks like it might be complaining about the content of the svn:date
> > revprop on that revision, though I can't see anything wrong with it via
> > DAV (I assume ViewCVS uses ra_local, though).
>
> ViewCVS uses direct repository access via the Subversion Python
> bindings (but *can* use any of the three RA layers, too, at the cost
> of years of your life waiting for responses).
>
> But yeesh -- I can't see anything wrong with that date, either.
> Weirdness. Guess I've some debugging to do today... Thanks for
> pointing this out, Malcolm!
>
svn_string_t (which svn_fs_txn_prop() [et al] uses) are counted strings.
I wondered if this is due to the difference between a property containing
"2005-10-25T14:52:07.936032Z" (r17005) and one containing something like
"2005-10-25T15:33:29.047905Z\0" (r17006). Of course, I've no way to
test that theory, since for all I know, ra_dav strips out everything
following a NUL byte.
Hmm. We should probably be performing elementary validation on the
contents of svn:xx revprops and node properties at property-set time. It
would be nice if we could guarantee that svn:data always contained a
valid date string, for example.(It would be nice if we could guarantee
that it always _existed_, but we don't seem to do that).
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ViewCVS broken for r17006
Posted by "C. Michael Pilato" <cm...@collab.net>.
Malcolm Rowe <ma...@farside.org.uk> writes:
> Does the fact that ViewCVS on svn.collab.net is throwing an exception
> for r17006 indicate that there's anything wrong with the SVN repository
> itself, or is it just a bug in ViewCVS?
>
> http://svn.collab.net/viewcvs/svn?rev=17006&view=rev
>
> It looks like it might be complaining about the content of the svn:date
> revprop on that revision, though I can't see anything wrong with it via
> DAV (I assume ViewCVS uses ra_local, though).
ViewCVS uses direct repository access via the Subversion Python
bindings (but *can* use any of the three RA layers, too, at the cost
of years of your life waiting for responses).
But yeesh -- I can't see anything wrong with that date, either.
Weirdness. Guess I've some debugging to do today... Thanks for
pointing this out, Malcolm!
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org