You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2002/06/11 13:58:57 UTC
Re: svn commit: rev 2151 - trunk/notes/difftools/pics
brane@tigris.org writes:
> Author: brane
> Date: 2002-06-11 13:15 GMT
> New Revision: 2151
>
> Modified:
> Log:
> Scratching my itch -- changing svn:mime-type to something browseable.
I was about to go back and add the affected path to this log message,
but then I thought about it: with the upcoming fix of
http://subversion.tigris.org/issues/show_bug.cgi?id=690
there's really no need to. So I left it alone, along with 2151, 2149,
2147, 2145, 2144, and 2143.
I've added a paragraph to HACKING about this. The log message for
that change does not say "* HACKING: ..."
:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2151 - trunk/notes/difftools/pics
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> Huh? The problem, that Branko is commenting on, is with the original email.
> The header of the mail was:
Oh, that was in the *mail* too?? I didn't realize that.
Brane was responding to a mail from me, which contained text
cut-and-pasted from two sources -- from the original commit email, and
also from
http://svn.collab.net/scripts/tweak-log.cgi
I assumed that the missing information was due to it not being in the
tweak-log.cgi output (which it's not), and that my cutting and pasting
had been done in such a way that it made it look like it wasn't in the
original mail.
You're right, though. It's not even in the original commit email, so
there is a bug. I've filed issue #732 about this..
> ---------------------------------------------------------
> Author: brane
> Date: 2002-06-11 13:15 GMT
> New Revision: 2151
>
> Modified:
> Log:
> Scratching my itch -- changing svn:mime-type to something browseable.
>
> ---------------------------------------------------------
>
> You can see that the Modified: section doesn't show any paths for the items
> with (only) property changes.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2151 - trunk/notes/difftools/pics
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jun 11, 2002 at 11:21:11AM -0500, Karl Fogel wrote:
> Branko Cibej <br...@xbc.nu> writes:
> > Modified what? This looks like a bug in the commit mail script, not
> > svn log itself. I was sort of relying on the mailer saying which file
> > was modified.
>
> I wasn't pasting from the commit mail script, but from somewhere else
> where this misbehavior is a known dependency of issue #690.
Huh? The problem, that Branko is commenting on, is with the original email.
The header of the mail was:
---------------------------------------------------------
Author: brane
Date: 2002-06-11 13:15 GMT
New Revision: 2151
Modified:
Log:
Scratching my itch -- changing svn:mime-type to something browseable.
---------------------------------------------------------
You can see that the Modified: section doesn't show any paths for the items
with (only) property changes.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2151 - trunk/notes/difftools/pics
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> Modified what? This looks like a bug in the commit mail script, not
> svn log itself. I was sort of relying on the mailer saying which file
> was modified.
I wasn't pasting from the commit mail script, but from somewhere else
where this misbehavior is a known dependency of issue #690.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: repository conversion on windows fails / binary file
Posted by Branko Čibej <br...@xbc.nu>.
Ryan Bloom wrote:
>>From: Greg Stein [mailto:gstein@lyra.org]
>>
>>On Tue, Jun 11, 2002 at 10:10:22PM +0200, Branko Cibej wrote:
>>
>>
>>>...
>>>The solution is to reopen the streams in binary mode, obviously. I
>>>wonder how you do that in APR.
>>>
>>>
>>Pass APR_BINARY to the apr_file_open() function. Not a problem.
>>
>>Of course, it appears that apr/file_io/win32/open.c doesn't even look
>>
>>
>for
>
>
>>that flag :-(
>>
>>
>
>That is a pretty major bug. :-(
>
>
>
>>Hmm. And reopening stdout/stdin in binary mode... oof. No fricking
>>
>>
>clue.
>
>We don't do that currently. You really only have two options as things
>stand today. 1) Close the file and re-open. 2) Implement
>apr_file_reopen (which devolves to option #1 in the worst case
>scenario).
>
>Ryan
>
>
/me has a more evil solution. Use apr_file_open_std*, as that bypasses
the CRT and uses the OS's file handles which don't know or care about
translation. The attached patch works on Win32.
Even if it's not the Totally Right Thing To Do, I vote we put it on
trunk/ and branches/fs-convert-2092/ and roll new tarballs, or at least
Win32 binaries.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: repository conversion on windows fails / binary file
Posted by Branko Čibej <br...@xbc.nu>.
Ryan Bloom wrote:
>>From: Greg Stein [mailto:gstein@lyra.org]
>>
>>On Tue, Jun 11, 2002 at 10:10:22PM +0200, Branko Cibej wrote:
>>
>>
>>>...
>>>The solution is to reopen the streams in binary mode, obviously. I
>>>wonder how you do that in APR.
>>>
>>>
>>Pass APR_BINARY to the apr_file_open() function. Not a problem.
>>
>>Of course, it appears that apr/file_io/win32/open.c doesn't even look
>>
>>
>for
>
>
>>that flag :-(
>>
>>
>
>That is a pretty major bug. :-(
>
>
>
>>Hmm. And reopening stdout/stdin in binary mode... oof. No fricking
>>
>>
>clue.
>
>We don't do that currently. You really only have two options as things
>stand today. 1) Close the file and re-open. 2) Implement
>apr_file_reopen (which devolves to option #1 in the worst case
>scenario).
>
>Ryan
>
>
/me has a more evil solution. Use apr_file_open_std*, as that bypasses
the CRT and uses the OS's file handles which don't know or care about
translation. The attached patch works on Win32.
Even if it's not the Totally Right Thing To Do, I vote we put it on
trunk/ and branches/fs-convert-2092/ and roll new tarballs, or at least
Win32 binaries.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: repository conversion on windows fails / binary file
Posted by Branko Čibej <br...@xbc.nu>.
Ryan Bloom wrote:
>>From: Greg Stein [mailto:gstein@lyra.org]
>>
>>On Tue, Jun 11, 2002 at 10:10:22PM +0200, Branko Cibej wrote:
>>
>>
>>>...
>>>The solution is to reopen the streams in binary mode, obviously. I
>>>wonder how you do that in APR.
>>>
>>>
>>Pass APR_BINARY to the apr_file_open() function. Not a problem.
>>
>>Of course, it appears that apr/file_io/win32/open.c doesn't even look for
>>
>>
>>that flag :-(
>>
>>
>
>That is a pretty major bug. :-(
>
>
It's not that bad, really. The Win32 apr_file_t uses the OS's file
handles, which don't know about newline translation and stuff. So
APR_BINARY is actually what you get. The "bug" is that you can't turn
it off, e.g., APR doesn't do newline translation for you.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
RE: repository conversion on windows fails / binary file
Posted by Ryan Bloom <rb...@covalent.net>.
> From: Greg Stein [mailto:gstein@lyra.org]
>
> On Tue, Jun 11, 2002 at 10:10:22PM +0200, Branko Cibej wrote:
> >...
> > The solution is to reopen the streams in binary mode, obviously. I
> > wonder how you do that in APR.
>
> Pass APR_BINARY to the apr_file_open() function. Not a problem.
>
> Of course, it appears that apr/file_io/win32/open.c doesn't even look
for
> that flag :-(
That is a pretty major bug. :-(
>
> Hmm. And reopening stdout/stdin in binary mode... oof. No fricking
clue.
We don't do that currently. You really only have two options as things
stand today. 1) Close the file and re-open. 2) Implement
apr_file_reopen (which devolves to option #1 in the worst case
scenario).
Ryan
RE: repository conversion on windows fails / binary file
Posted by Ryan Bloom <rb...@covalent.net>.
> From: Greg Stein [mailto:gstein@lyra.org]
>
> On Tue, Jun 11, 2002 at 10:10:22PM +0200, Branko Cibej wrote:
> >...
> > The solution is to reopen the streams in binary mode, obviously. I
> > wonder how you do that in APR.
>
> Pass APR_BINARY to the apr_file_open() function. Not a problem.
>
> Of course, it appears that apr/file_io/win32/open.c doesn't even look
for
> that flag :-(
That is a pretty major bug. :-(
>
> Hmm. And reopening stdout/stdin in binary mode... oof. No fricking
clue.
We don't do that currently. You really only have two options as things
stand today. 1) Close the file and re-open. 2) Implement
apr_file_reopen (which devolves to option #1 in the worst case
scenario).
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: repository conversion on windows fails / binary file
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jun 11, 2002 at 10:10:22PM +0200, Branko Cibej wrote:
>...
> The solution is to reopen the streams in binary mode, obviously. I
> wonder how you do that in APR.
Pass APR_BINARY to the apr_file_open() function. Not a problem.
Of course, it appears that apr/file_io/win32/open.c doesn't even look for
that flag :-(
Hmm. And reopening stdout/stdin in binary mode... oof. No fricking clue.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: repository conversion on windows fails / binary file
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jun 11, 2002 at 10:10:22PM +0200, Branko Cibej wrote:
>...
> The solution is to reopen the streams in binary mode, obviously. I
> wonder how you do that in APR.
Pass APR_BINARY to the apr_file_open() function. Not a problem.
Of course, it appears that apr/file_io/win32/open.c doesn't even look for
that flag :-(
Hmm. And reopening stdout/stdin in binary mode... oof. No fricking clue.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: repository conversion on windows fails / binary file
Posted by Ben Collins-Sussman <su...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> [Regarding datestamps: ATM, the client knows how to parse old-style
> and new-style (ISO8601) stamps; Hadaka plans to change the server
^^^^^^
Oops, sorry, I mean "Naked".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: repository conversion on windows fails / binary file
Posted by Ben Collins-Sussman <su...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> > The solution is to reopen the streams in binary mode, obviously. I
> > wonder how you do that in APR.
> >
> BTW, I can dump and reload a repo that only contains text files. And I
> just confirmed my suspicions by adding a ^Z in a file in the wrong
> place.
Branko, you rock. Thank you so much for finding the root of the problem.
> * Where are the checksums? I thought there would be checksums ...
Just never got around to it, "in the interest of rapidly getting the
product to market." It's an option in the dumpstream spec; I figured
we'd put it into version 2 of the dumpstream format someday. Feel
free to add them, though.
> * Why are we dumping timestamps in the old, weird format that we're
> about to forget how to parse?)
Timestamps? The only timestamps in the dumpstream are the values of
the svn:date property attached to revisions. That's generated by
libsvn_fs when you commit a revision... so the dumper has nothing to
do with it; those datestrings were made by the repository long ago.
[Regarding datestamps: ATM, the client knows how to parse old-style
and new-style (ISO8601) stamps; Hadaka plans to change the server
libraries to start producing *only* ISO8601 formats RSN.]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: repository conversion on windows fails / binary file
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
> Ben Collins-Sussman wrote:
>
>> Hontvari Jozsef <ho...@solware.com> writes:
>>
>>
>>
>>> From: "Ben Collins-Sussman"
>>>
>>>
>>>> Is there any way we can look at the dumpfile so we can reproduce?
>>>>
>>>
>>> I can reproduce it easily, I make a new repository with the current
>>> windows
>>> binary, r2140, svn import a single file, dump, delete the
>>> repository, create
>>> another repository, svnadmin load, and it fails with a similar message.
>>>
>>> I have attached the example dump file from the above process.
>>>
>>
>>
>> I just loaded the dumpfile into my emacs, and noticed that the whole
>> dumpfile is CRLF terminated. I bet that's screwing up the 'svnadmin
>> load' parser -- I think it's looking for '\n' specifically at the end
>> of each line.
>>
>> Hmmm, I'm not sure I understand why 'svnadmin dump' is producing a
>> CRLF file at all, I need to examine... maybe my hypothesis is wrong.
>>
>>
> They're CRLF-terminated because we use svn_stream_from_stdio to open
> the dumper and loader streams. The stdio streams are translated by
> default on Windows.
>
> I don't know what happens during the load (LF <-> CRLF translation
> should be reversible), but I suspect that the the translated stdio
> thinks it has an EOF when it sees a ^Z in the input stream, which
> interestingly enough occurs very near the beginning of a Word document.
>
> Is that broken? Well, it's only true of translated streams, and if you
> write binary data to a stream that believes it's text, you get what
> you deserve.
>
> The solution is to reopen the streams in binary mode, obviously. I
> wonder how you do that in APR.
>
BTW, I can dump and reload a repo that only contains text files. And I
just confirmed my suspicions by adding a ^Z in a file in the wrong place.
(And I have a couple of questions about the dump format:
* Where are the checksums? I thought there would be checksums ...
* Why are we dumping timestamps in the old, weird format that we're
about to forget how to parse?)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: repository conversion on windows fails / binary file
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>Hontvari Jozsef <ho...@solware.com> writes:
>
>
>
>>From: "Ben Collins-Sussman"
>>
>>
>>>Is there any way we can look at the dumpfile so we can reproduce?
>>>
>>>
>>I can reproduce it easily, I make a new repository with the current windows
>>binary, r2140, svn import a single file, dump, delete the repository, create
>>another repository, svnadmin load, and it fails with a similar message.
>>
>>I have attached the example dump file from the above process.
>>
>>
>
>I just loaded the dumpfile into my emacs, and noticed that the whole
>dumpfile is CRLF terminated. I bet that's screwing up the 'svnadmin
>load' parser -- I think it's looking for '\n' specifically at the end
>of each line.
>
>Hmmm, I'm not sure I understand why 'svnadmin dump' is producing a
>CRLF file at all, I need to examine... maybe my hypothesis is wrong.
>
>
They're CRLF-terminated because we use svn_stream_from_stdio to open the
dumper and loader streams. The stdio streams are translated by default
on Windows.
I don't know what happens during the load (LF <-> CRLF translation
should be reversible), but I suspect that the the translated stdio
thinks it has an EOF when it sees a ^Z in the input stream, which
interestingly enough occurs very near the beginning of a Word document.
Is that broken? Well, it's only true of translated streams, and if you
write binary data to a stream that believes it's text, you get what you
deserve.
The solution is to reopen the streams in binary mode, obviously. I
wonder how you do that in APR.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: repository conversion on windows fails / binary file
Posted by Ben Collins-Sussman <su...@collab.net>.
Hontvari Jozsef <ho...@solware.com> writes:
> From: "Ben Collins-Sussman"
> > Is there any way we can look at the dumpfile so we can reproduce?
>
> I can reproduce it easily, I make a new repository with the current windows
> binary, r2140, svn import a single file, dump, delete the repository, create
> another repository, svnadmin load, and it fails with a similar message.
>
> I have attached the example dump file from the above process.
I just loaded the dumpfile into my emacs, and noticed that the whole
dumpfile is CRLF terminated. I bet that's screwing up the 'svnadmin
load' parser -- I think it's looking for '\n' specifically at the end
of each line.
Hmmm, I'm not sure I understand why 'svnadmin dump' is producing a
CRLF file at all, I need to examine... maybe my hypothesis is wrong.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: repository conversion on windows fails / binary file
Posted by Hontvari Jozsef <ho...@solware.com>.
From: "Ben Collins-Sussman"
> Is there any way we can look at the dumpfile so we can reproduce?
I can reproduce it easily, I make a new repository with the current windows
binary, r2140, svn import a single file, dump, delete the repository, create
another repository, svnadmin load, and it fails with a similar message.
I have attached the example dump file from the above process.
----- Original Message -----
From: "Ben Collins-Sussman" <su...@collab.net>
To: "Hontvari Jozsef" <ho...@solware.com>
Cc: "SVN Dev List" <de...@subversion.tigris.org>
Sent: Tuesday, June 11, 2002 5:20 PM
Subject: Re: repository conversion on windows fails / binary file
> Hontvari Jozsef <ho...@solware.com> writes:
>
> > I dumped an old repository with r2092 then I tried to load it with r2140
on
> > windows. I got the following error on a (binary) Word document:
> >
> > ...
> > * adding path : server/trunk/dumpDatabase.bat ... done.
> > * adding path : server/trunk/model ... done.
> > * adding path : server/trunk/model/specification.doc ...
> > svn_error: #21009 : <Incomplete data>
> > Premature end of content data in dumpstream.
> >
> > I guess this was the only binary file in the repository and it was not
> > modified during the life of this repository. (Losing the repository is
not a
> > problem for me, but it may indicate a bug in the dump/load mechanism)
>
> The fact that the file was binary isn't relevant; svn treats all file
> contents as binary data.
>
> Is there any way we can look at the dumpfile so we can reproduce?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: repository conversion on windows fails / binary file
Posted by Ben Collins-Sussman <su...@collab.net>.
Hontvari Jozsef <ho...@solware.com> writes:
> I dumped an old repository with r2092 then I tried to load it with r2140 on
> windows. I got the following error on a (binary) Word document:
>
> ...
> * adding path : server/trunk/dumpDatabase.bat ... done.
> * adding path : server/trunk/model ... done.
> * adding path : server/trunk/model/specification.doc ...
> svn_error: #21009 : <Incomplete data>
> Premature end of content data in dumpstream.
>
> I guess this was the only binary file in the repository and it was not
> modified during the life of this repository. (Losing the repository is not a
> problem for me, but it may indicate a bug in the dump/load mechanism)
The fact that the file was binary isn't relevant; svn treats all file
contents as binary data.
Is there any way we can look at the dumpfile so we can reproduce?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
repository conversion on windows fails / binary file
Posted by Hontvari Jozsef <ho...@solware.com>.
I dumped an old repository with r2092 then I tried to load it with r2140 on
windows. I got the following error on a (binary) Word document:
...
* adding path : server/trunk/dumpDatabase.bat ... done.
* adding path : server/trunk/model ... done.
* adding path : server/trunk/model/specification.doc ...
svn_error: #21009 : <Incomplete data>
Premature end of content data in dumpstream.
I guess this was the only binary file in the repository and it was not
modified during the life of this repository. (Losing the repository is not a
problem for me, but it may indicate a bug in the dump/load mechanism)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2151 - trunk/notes/difftools/pics
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>brane@tigris.org writes:
>
>
>>Author: brane
>>Date: 2002-06-11 13:15 GMT
>>New Revision: 2151
>>
>>Modified:
>>
Modified what? This looks like a bug in the commit mail script, not svn
log itself. I was sort of relying on the mailer saying which file was
modified.
>> Log:
>>Scratching my itch -- changing svn:mime-type to something browseable.
>>
>>
>
>I was about to go back and add the affected path to this log message,
>but then I thought about it: with the upcoming fix of
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=690
>
>there's really no need to. So I left it alone, along with 2151, 2149,
>2147, 2145, 2144, and 2143.
>
>I've added a paragraph to HACKING about this. The log message for
>that change does not say "* HACKING: ..."
>
>:-)
>
>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org