You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Wesley J. Landaker" <wj...@icecavern.net> on 2005/06/10 00:14:57 UTC
BUG(?): "svn diff" behaves incorrectly on symbolic links pointing to binary files
Hi again,
Again a quick intro: I'm a Debian developer who is helping out with the
subversion packages. This bug was reported recently, and I thought I'd
forward it here for your thoughts:
On Tue, 29 Mar 2005, Vincent Lefevre <vi...@vinc17.org> wrote:
> When I do a "svn diff" in a directory where a symbolic link has been
> added, Subversion does a diff on this link, even when the file pointed
> to is a binary file. The consequence is that these binary data are
> sent to the terminal (in my case, xterm). This had two very bad side
> effects:
>
> 1) The terminal was trashed (I had to do a "reset").
>
> 2) A part of the data was sent to the printer! I suppose that some
> escape sequence was interpreted as a request for printing.
>
> Note: I posted a message about this problem to the Subversion dev
> mailing-list on 25 Mar 2005, but I haven't got any reply yet.
(Well, sorry if it's a repeat--I'm subscribed to this list, but I don't
remember any discussion about this issue.)
--
Wesley J. Landaker <wj...@icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
Re: BUG(?): "svn diff" behaves incorrectly on symbolic links pointing to binary files
Posted by "Wesley J. Landaker" <wj...@icecavern.net>.
On Monday 13 June 2005 16:08, kfogel@collab.net wrote:
> I agree this is a bug. Would you be willing to file an issue for it
> in our tracker? Just make sure the issue points to this mail thread,
> so future discussion is easily findable.
Wow, that took a bit of hoop jumping to get signed up... =) But, no problem;
it's filed at: <http://subversion.tigris.org/issues/show_bug.cgi?id=2334>.
> Thanks for helping out with the Subversion packages on Debian, by the
> way. I use Debian at home and at work :-).
Good choice! =)
--
Wesley J. Landaker <wj...@icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
Re: BUG(?): "svn diff" behaves incorrectly on symbolic links pointing to binary files
Posted by kf...@collab.net.
"Wesley J. Landaker" <wj...@icecavern.net> writes:
> Okay, well Vincent was the original reporter for this bug on the Debian
> side, and it sounds like what he was seeing is fixed, so I'll go ahead and
> close this bug (both in Debian, and in the Subversion issue tracker).
Yup. Thanks for handling the bookkeeping (and your guess was right,
I'd forgotten that you were not the original reporter, thanks for
clarifying).
> My gut feel is that since svn diff in all other cases goes out of it's way
> not to print binary data to the screen, it should not in this case either,
> even if it's technically the user's own fault. But, I don't feel super
> strongly about it, since the reproduction recipe(s) for this are use cases
> that I personally would probably not encounter very often.
>
> Anyway, as far as if this behavior is correct or if it should be fixed, I'll
> let you guys work it out for now, as I will be out of town for the next
> week and a half (so I won't be able to follow this thread with much vigor).
Well, what constitutes screen-unfriendly binary data depends on the
locale. I'm not against Subversion behaving better here, if we can
define what "better" means. But in any case, it's a different issue
than the ones originally opened, so those should be closed no matter
what. We may open a new one, if we decide to make this other change.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: BUG(?): "svn diff" behaves incorrectly on symbolic links pointing to binary files
Posted by "Wesley J. Landaker" <wj...@icecavern.net>.
Consolidating a few messages in this reply:
On Wednesday 15 June 2005 05:25, Vincent Lefevre wrote:
> On 2005-06-14 12:51:12 -0500, kfogel@collab.net wrote:
> > Well -- hmmm, and that would seem to be the recipe implied in the
> > original report, too. Vincent? Can you reproduce this bug with
> > Subversion 1.2 or with head of trunk?
>
> With Subversion 1.2 (latest Debian package), I confirm that the
> behavior is correct:
Okay, well Vincent was the original reporter for this bug on the Debian
side, and it sounds like what he was seeing is fixed, so I'll go ahead and
close this bug (both in Debian, and in the Subversion issue tracker).
On Tuesday 14 June 2005 21:42, kfogel@collab.net wrote:
> Oh.
>
> This behavior has nothing to do with symlinks. If you 'svn add' a
> text file, then replace its contents with binary data, Subversion
> never finds out that it changed from text to binary, and will happily
> diff it (unhappily for the user, of course).
>
> A reproduction recipe that involves no symlinks:
On Wednesday 15 June 2005 05:45, Vincent Lefevre wrote:
> Concerning this point, I think this is a bug (but a different one):
> if in the diff, there are non-printable characters, then they should
> be filtered out when the output is a tty. Otherwise this can mess up
> the terminal. (I'm not sure whether this problem is unix-specific or
> more general...)
My gut feel is that since svn diff in all other cases goes out of it's way
not to print binary data to the screen, it should not in this case either,
even if it's technically the user's own fault. But, I don't feel super
strongly about it, since the reproduction recipe(s) for this are use cases
that I personally would probably not encounter very often.
Anyway, as far as if this behavior is correct or if it should be fixed, I'll
let you guys work it out for now, as I will be out of town for the next
week and a half (so I won't be able to follow this thread with much vigor).
=)
--
Wesley J. Landaker <wj...@icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
Re: BUG(?): "svn diff" behaves incorrectly on symbolic links pointing to binary files
Posted by Vincent Lefevre <vi...@vinc17.org>.
[Sorry, this is old, but I'm catching up with all my mail...]
On 2005-06-16 10:40:33 -0400, Charles Bailey wrote:
> On 6/15/05, Vincent Lefevre <vi...@vinc17.org> wrote:
> > if in the diff, there are non-printable characters, then they should
> > be filtered out when the output is a tty. Otherwise this can mess up
> > the terminal. (I'm not sure whether this problem is unix-specific or
> > more general...)
>
> The theory here sounds reasonable. (I'm making the simplifying
> assumption that people generall don't want terminal control sequences
> sent in their diffs. Do people use them -- for instance, as text
> formatting codes -- in ways that they want to see onscreen?)
Note that if people use control sequences in their files to control
what the file would look like (for instance to change the color),
then the behavior would not necessarily be right in a diff since a
diff contains only some parts of the files, so that some important
escape sequences could be missing.
Also you can't assume that diff will always give what the user expects.
For instance, the files could be in an encoding different from the
locales, and Subversion won't convert these files.
> I'm not sure it'd be easy to define "non-printable", since that'll
> depend on the screen and the locale, though.
Well, they depend on the locale only. I think that using isprint()
would be sufficient.
> If the practical goal is to avoid wedging terminals by sending
> control sequences, perhaps it'd be enough to escape ASCII control
> codes (i.e. 0x00-0x1f) other than CR and LF.
0x7f-0x9f are also control characters with ISO-8859 encodings.
That's why isprint() should be used.
> Would such a change be specific to diffs, or would it extend to other
> terminal output, such as property values?
To all terminal output (filenames, etc.).
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: BUG(?): "svn diff" behaves incorrectly on symbolic links pointing to binary files
Posted by Charles Bailey <ba...@gmail.com>.
On 6/15/05, Vincent Lefevre <vi...@vinc17.org> wrote:
> On 2005-06-14 22:42:13 -0500, kfogel@collab.net wrote:
> > This behavior has nothing to do with symlinks. If you 'svn add' a
> > text file, then replace its contents with binary data, Subversion
> > never finds out that it changed from text to binary, and will happily
> > diff it (unhappily for the user, of course).
>
> Concerning this point, I think this is a bug (but a different one):
> if in the diff, there are non-printable characters, then they should
> be filtered out when the output is a tty. Otherwise this can mess up
> the terminal. (I'm not sure whether this problem is unix-specific or
> more general...)
The theory here sounds reasonable. (I'm making the simplifying
assumption that people generall don't want terminal control sequences
sent in their diffs. Do people use them -- for instance, as text
formatting codes -- in ways that they want to see onscreen?)
I'm not sure it'd be easy to define "non-printable", since that'll
depend on the screen and the locale, though. If the practical goal is
to avoid wedging terminals by sending control sequences, perhaps it'd
be enough to escape ASCII control codes (i.e. 0x00-0x1f) other than CR
and LF.
Can anyone who knows more than I about various terminals' screen
control comment on how often control sequences live outside this
range. (I'm not considering codes of the form <ESC><non-ctrl-byte>+,
since escaping ASCII control codes would prevent this from hosing the
terminal, at the cost of some screen droppings in the output.)
Would such a change be specific to diffs, or would it extend to other
terminal output, such as property values?
--
Regards,
Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: BUG(?): "svn diff" behaves incorrectly on symbolic links pointing to binary files
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-06-14 22:42:13 -0500, kfogel@collab.net wrote:
> This behavior has nothing to do with symlinks. If you 'svn add' a
> text file, then replace its contents with binary data, Subversion
> never finds out that it changed from text to binary, and will happily
> diff it (unhappily for the user, of course).
Concerning this point, I think this is a bug (but a different one):
if in the diff, there are non-printable characters, then they should
be filtered out when the output is a tty. Otherwise this can mess up
the terminal. (I'm not sure whether this problem is unix-specific or
more general...)
Other unix commands already do such kind of things, e.g. less (for
file contents), and ls and find (for filenames). Some commands (e.g.
diff and grep) just detect binary files, but this is not sufficient.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: BUG(?): "svn diff" behaves incorrectly on symbolic links pointing to binary files
Posted by kf...@collab.net.
"Wesley J. Landaker" <wj...@icecavern.net> writes:
> > Well -- hmmm, and that would seem to be the recipe implied in the
> > original report, too. Vincent? Can you reproduce this bug with
> > Subversion 1.2 or with head of trunk?
>
> It took me a couple tries to reproduce it. The key seems to be that "text"
> in that example WAS a text file. If it was originally a binary file, this
> doesn't happen.
Oh.
This behavior has nothing to do with symlinks. If you 'svn add' a
text file, then replace its contents with binary data, Subversion
never finds out that it changed from text to binary, and will happily
diff it (unhappily for the user, of course).
A reproduction recipe that involves no symlinks:
#!/bin/sh
rm -rf bugdir
mkdir bugdir
cd bugdir
svnadmin create repos
svn co file://`pwd`/repos wc
cd wc
echo "text file" > text
svn add text
svn commit -m "adding a text file"
svn diff
cp /bin/ls text
svn diff
This is expected behavior. There's no bug here; you can close the
issue.
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: BUG(?): "svn diff" behaves incorrectly on symbolic links pointing to binary files
Posted by "Wesley J. Landaker" <wj...@icecavern.net>.
On Tuesday 14 June 2005 11:51, kfogel@collab.net wrote:
> It hadn't occurred to me that it mattered if the destination is
> versioned. The method I was envisioning was:
>
> When running 'svn diff' on a link, determine the textyness of the
> link target on the fly, using the same svn_io_detect_mimetype() method
> that we use at add/import time, and do not show the diff if the target
> is not texty.
From my previous example, if I add:
$ svn add text.symlink
$ svn diff
I get the same result.
> Well -- hmmm, and that would seem to be the recipe implied in the
> original report, too. Vincent? Can you reproduce this bug with
> Subversion 1.2 or with head of trunk?
It took me a couple tries to reproduce it. The key seems to be that "text"
in that example WAS a text file. If it was originally a binary file, this
doesn't happen.
--
Wesley J. Landaker <wj...@icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
Re: BUG(?): "svn diff" behaves incorrectly on symbolic links pointing to binary files
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-06-14 12:51:12 -0500, kfogel@collab.net wrote:
> Well -- hmmm, and that would seem to be the recipe implied in the
> original report, too. Vincent? Can you reproduce this bug with
> Subversion 1.2 or with head of trunk?
With Subversion 1.2 (latest Debian package), I confirm that the
behavior is correct:
[...]
ay:~/wc> svn diff
Index: link
===================================================================
--- link (revision 0)
+++ link (revision 0)
@@ -0,0 +1 @@
+link file
\ No newline at end of file
Property changes on: link
___________________________________________________________________
Name: svn:special
+ *
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: BUG(?): "svn diff" behaves incorrectly on symbolic links pointing to binary files
Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> Really? So what is the correct behaviour? Are you suggesting that
> the client uses the svn:mime-type of the link destination rather than
> the link itself? What happens if the destination is not versioned?
It hadn't occurred to me that it mattered if the destination is
versioned. The method I was envisioning was:
When running 'svn diff' on a link, determine the textyness of the
link target on the fly, using the same svn_io_detect_mimetype() method
that we use at add/import time, and do not show the diff if the target
is not texty.
But now that you mention it, we should treat versioned destinations
differently from unversioned ones. If the dest is versioned, then
just determine textyness by examining the file's properties as usual;
if it's unversioned, then follow the above recipe.
> How did you reproduce the bug anyway?
>
> $ svnadmin create repo
> $ svn co file://`pwd`/repo wc
> Checked out revision 0.
> $ cp /bin/ls wc/dst
> $ svn add wc/dst
> A (bin) wc/dst
> $ ln -sf dst wc/src
> $ svn add wc/src
> A wc/src
> $ svn diff wc
> Index: wc/src
> ===================================================================
> --- wc/src (revision 0)
> +++ wc/src (revision 0)
> @@ -0,0 +1 @@
> +link dst
> \ No newline at end of file
>
> Property changes on: wc/src
> ___________________________________________________________________
> Name: svn:special
> + *
>
> Index: wc/dst
> ===================================================================
> Cannot display: file marked as a binary type.
> svn:mime-type = application/octet-stream
>
> Property changes on: wc/dst
> ___________________________________________________________________
> Name: svn:executable
> + *
> Name: svn:mime-type
> + application/octet-stream
Well -- hmmm, and that would seem to be the recipe implied in the
original report, too. Vincent? Can you reproduce this bug with
Subversion 1.2 or with head of trunk?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: BUG(?): "svn diff" behaves incorrectly on symbolic links pointing to binary files
Posted by "Wesley J. Landaker" <wj...@icecavern.net>.
On Monday 13 June 2005 20:05, Philip Martin wrote:
> How did you reproduce the bug anyway?
Here is a recipe:
$ svn --version | head -2
svn, version 1.2.0 (r14790)
compiled Jun 15 2005, 00:07:14
$ mkdir /tmp/svndiffsymlinkbug
$ cd /tmp/svndiffsymlinkbug/
$ svnadmin create repos
$ svn co file://`pwd`/repos wc
$ cd wc
$ echo "text file" > text
$ svn add text
$ svn commit -m "adding a text file"
$ ln -s text text.symlink
$ svn diff
$ cp /bin/ls text
$ svn diff | wc
wc: standard input:7: Invalid or incomplete multibyte or wide character
wc: standard input:8: Invalid or incomplete multibyte or wide character
wc: standard input:9: Invalid or incomplete multibyte or wide character
wc: standard input:10: Invalid or incomplete multibyte or wide character
wc: standard input:11: Invalid or incomplete multibyte or wide character
wc: standard input:12: Invalid or incomplete multibyte or wide character
wc: standard input:13: Invalid or incomplete multibyte or wide character
wc: standard input:14: Invalid or incomplete multibyte or wide character
wc: standard input:15: Invalid or incomplete multibyte or wide character
wc: standard input:16: Invalid or incomplete multibyte or wide character
wc: standard input:17: Invalid or incomplete multibyte or wide character
wc: standard input:18: Invalid or incomplete multibyte or wide character
wc: standard input:19: Invalid or incomplete multibyte or wide character
wc: standard input:20: Invalid or incomplete multibyte or wide character
wc: standard input:21: Invalid or incomplete multibyte or wide character
wc: standard input:22: Invalid or incomplete multibyte or wide character
wc: standard input:23: Invalid or incomplete multibyte or wide character
wc: standard input:24: Invalid or incomplete multibyte or wide character
wc: standard input:25: Invalid or incomplete multibyte or wide character
wc: standard input:26: Invalid or incomplete multibyte or wide character
wc: standard input:27: Invalid or incomplete multibyte or wide character
wc: standard input:28: Invalid or incomplete multibyte or wide character
wc: standard input:29: Invalid or incomplete multibyte or wide character
wc: standard input:30: Invalid or incomplete multibyte or wide character
wc: standard input:32: Invalid or incomplete multibyte or wide character
wc: standard input:33: Invalid or incomplete multibyte or wide character
wc: standard input:34: Invalid or incomplete multibyte or wide character
wc: standard input:35: Invalid or incomplete multibyte or wide character
wc: standard input:36: Invalid or incomplete multibyte or wide character
wc: standard input:37: Invalid or incomplete multibyte or wide character
wc: standard input:38: Invalid or incomplete multibyte or wide character
wc: standard input:39: Invalid or incomplete multibyte or wide character
wc: standard input:40: Invalid or incomplete multibyte or wide character
wc: standard input:41: Invalid or incomplete multibyte or wide character
wc: standard input:42: Invalid or incomplete multibyte or wide character
wc: standard input:43: Invalid or incomplete multibyte or wide character
wc: standard input:44: Invalid or incomplete multibyte or wide character
wc: standard input:45: Invalid or incomplete multibyte or wide character
wc: standard input:46: Invalid or incomplete multibyte or wide character
wc: standard input:47: Invalid or incomplete multibyte or wide character
wc: standard input:48: Invalid or incomplete multibyte or wide character
wc: standard input:49: Invalid or incomplete multibyte or wide character
wc: standard input:50: Invalid or incomplete multibyte or wide character
wc: standard input:51: Invalid or incomplete multibyte or wide character
wc: standard input:52: Invalid or incomplete multibyte or wide character
wc: standard input:53: Invalid or incomplete multibyte or wide character
wc: standard input:54: Invalid or incomplete multibyte or wide character
wc: standard input:55: Invalid or incomplete multibyte or wide character
wc: standard input:56: Invalid or incomplete multibyte or wide character
wc: standard input:59: Invalid or incomplete multibyte or wide character
wc: standard input:124: Invalid or incomplete multibyte or wide character
wc: standard input:128: Invalid or incomplete multibyte or wide character
wc: standard input:129: Invalid or incomplete multibyte or wide character
wc: standard input:153: Invalid or incomplete multibyte or wide character
wc: standard input:154: Invalid or incomplete multibyte or wide character
wc: standard input:155: Invalid or incomplete multibyte or wide character
wc: standard input:156: Invalid or incomplete multibyte or wide character
wc: standard input:157: Invalid or incomplete multibyte or wide character
wc: standard input:158: Invalid or incomplete multibyte or wide character
wc: standard input:159: Invalid or incomplete multibyte or wide character
wc: standard input:160: Invalid or incomplete multibyte or wide character
wc: standard input:161: Invalid or incomplete multibyte or wide character
wc: standard input:162: Invalid or incomplete multibyte or wide character
wc: standard input:163: Invalid or incomplete multibyte or wide character
wc: standard input:164: Invalid or incomplete multibyte or wide character
wc: standard input:165: Invalid or incomplete multibyte or wide character
wc: standard input:166: Invalid or incomplete multibyte or wide character
wc: standard input:167: Invalid or incomplete multibyte or wide character
168 1411 61343
--
Wesley J. Landaker <wj...@icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
Re: BUG(?): "svn diff" behaves incorrectly on symbolic links
pointing to binary files
Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:
> "Wesley J. Landaker" <wj...@icecavern.net> writes:
>> Again a quick intro: I'm a Debian developer who is helping out with the
>> subversion packages. This bug was reported recently, and I thought I'd
>> forward it here for your thoughts:
>>
>> On Tue, 29 Mar 2005, Vincent Lefevre <vi...@vinc17.org> wrote:
>> > When I do a "svn diff" in a directory where a symbolic link has been
>> > added, Subversion does a diff on this link, even when the file pointed
>> > to is a binary file. The consequence is that these binary data are
>> > sent to the terminal (in my case, xterm). This had two very bad side
>> > effects:
>> >
>> > 1) The terminal was trashed (I had to do a "reset").
>> >
>> > 2) A part of the data was sent to the printer! I suppose that some
>> > escape sequence was interpreted as a request for printing.
>> >
>> > Note: I posted a message about this problem to the Subversion dev
>> > mailing-list on 25 Mar 2005, but I haven't got any reply yet.
>>
>> (Well, sorry if it's a repeat--I'm subscribed to this list, but I don't
>> remember any discussion about this issue.)
>
> I agree this is a bug.
Really? So what is the correct behaviour? Are you suggesting that
the client uses the svn:mime-type of the link destination rather than
the link itself? What happens if the destination is not versioned?
How did you reproduce the bug anyway?
$ svnadmin create repo
$ svn co file://`pwd`/repo wc
Checked out revision 0.
$ cp /bin/ls wc/dst
$ svn add wc/dst
A (bin) wc/dst
$ ln -sf dst wc/src
$ svn add wc/src
A wc/src
$ svn diff wc
Index: wc/src
===================================================================
--- wc/src (revision 0)
+++ wc/src (revision 0)
@@ -0,0 +1 @@
+link dst
\ No newline at end of file
Property changes on: wc/src
___________________________________________________________________
Name: svn:special
+ *
Index: wc/dst
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes on: wc/dst
___________________________________________________________________
Name: svn:executable
+ *
Name: svn:mime-type
+ application/octet-stream
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: BUG(?): "svn diff" behaves incorrectly on symbolic links pointing to binary files
Posted by kf...@collab.net.
"Wesley J. Landaker" <wj...@icecavern.net> writes:
> Again a quick intro: I'm a Debian developer who is helping out with the
> subversion packages. This bug was reported recently, and I thought I'd
> forward it here for your thoughts:
>
> On Tue, 29 Mar 2005, Vincent Lefevre <vi...@vinc17.org> wrote:
> > When I do a "svn diff" in a directory where a symbolic link has been
> > added, Subversion does a diff on this link, even when the file pointed
> > to is a binary file. The consequence is that these binary data are
> > sent to the terminal (in my case, xterm). This had two very bad side
> > effects:
> >
> > 1) The terminal was trashed (I had to do a "reset").
> >
> > 2) A part of the data was sent to the printer! I suppose that some
> > escape sequence was interpreted as a request for printing.
> >
> > Note: I posted a message about this problem to the Subversion dev
> > mailing-list on 25 Mar 2005, but I haven't got any reply yet.
>
> (Well, sorry if it's a repeat--I'm subscribed to this list, but I don't
> remember any discussion about this issue.)
I agree this is a bug. Would you be willing to file an issue for it
in our tracker? Just make sure the issue points to this mail thread,
so future discussion is easily findable.
Thanks for helping out with the Subversion packages on Debian, by the
way. I use Debian at home and at work :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org