MantisBT - Subversion for OS/2 & eCS
View Issue Details
0000534Subversion for OS/2 & eCSBugpublic2012-04-16 08:382015-09-15 06:13
Reporterxhajt03 
Assigned Topsmedley 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformI386OSeCSOS Version1.0 (last FP)
Summary0000534: SVN commands diff and merge broken
DescriptionI use the OS/2 client for accessing a Subversion server running on a Unix (Linux) machine - I'm not not sure if it matters, but I suspect that it might) because of the changes necessary when handling text files and using svn:eol-style property set to "native". When trying to use 'svn diff' to show local modifications, the output is completely broken (the same is true for command 'svn merge' - most probably because that one also uses 'svn diff' internally).
Steps To ReproduceLet's have a file with the following content stored in the SVN server ('*****' used only here to denote start and end):
*****
Original line 1

*****

I make the following local modification:
*****
Original line 1
Modified line 2
*****

Now I run svn diff on that file and get:
*****
Index: testfile.txt
===================================================================
--- testfile.txt (revision XYZ)
+++ testfile.txt (working copy)
@@ -1 +1,2 @@
-Original line 1
               +
                +Modified line 2Original line 1
\ No newline at end of file
*****

If I modify the file to the following:
*****
Original line 1
Inserted line 2
Modified line 3
*****

I get the following result of svn diff:
*****
Index: testfile.txt
===================================================================
--- testfile.txt (revision XYZ)
+++ testfile.txt (working copy)
@@ -1 +1,3 @@
-Original line 1
               +
                +
                 +Original line 1Inserted line 2Modified line 3
\ No newline at end of file
*****

I also noticed that the original version of the file kept in .svn\pristine is stored with Unix line endings (LF only) whereas my local copy uses CRLF (i.e. the style native on OS/2). This by itself is probably normal because I noticed that the same is true for these files on Win32 (also SVN client 1.7.4), but the client probably needs to make sure to translate the line endings as appropriate when comparing the local files to the internally stored baseline.
Additional InformationSVN version 1.7.4 built on the 12th of March 2012 (subversion-1.7.4-os2-20120312.zip).
TagsNo tags attached.
Attached Files? diff (6,453) 2013-07-29 01:24
http://mantis.smedley.id.au/file_download.php?file_id=297&type=bug

Notes
(0002324)
psmedley   
2012-10-04 06:05   
is it possible for me to access the svn server in question to make it easier to reproduce locally?

Have you tested with svn 1.6.x on OS2 to confirm this is a regression with 1.7.x?
(0002461)
maazl   
2013-07-29 01:34   
I can confirm this problem. It does not apply to a 1.6 working copy.
It makes no difference whether the working copy is a result of svn upgrade or svn checkout.

As soon as a file gets modifies the entire file content is reported as difference. Obviously all line breaks are removed from the working copy's content an placed at the front before diff. See attached example. I only added an empty line at the end.

I also use a Linux based repository over the svn protocol. I think this does not matter directly, since svn diff is a local operation. But it might trigger the need for the line break conversion.

Unfortunately the server is in the intranet. So you can't use it for testing.
(0002462)
maazl   
2013-07-29 03:48   
(Last edited: 2013-07-29 03:49)
The problem is even larger. Commiting from a 1.7 working directory creates garbage in the working copy. In fact lines, containing only a braces like
{
or
}
or even
{}
are also moved to the beginning of the file, resulting in invalid code.
But not all of the removed characters show up at the beginning. Some are moved somewhere else. Looks like svn 1.7 has a special C merger that gets completely confused.
The invalid changes are only applied to the local working copy but not to the server. The pristine files are also OK.

(0002569)
xhajt03   
2013-10-21 07:34   
(Last edited: 2013-10-21 07:38)
Oops, I haven't noticed the request for getting access to the server (I received no notification, although I'd expect it on updates of bug reports created by me). :-( Anyway, if read access is sufficient (which it should be, because it can be reproduced without any commits as described in the report), then you can simply use svn.freepascal.org for this testing (see link Development on http://www.freepascal.org for details regarding paths for repositories available on that server).

If read access isn't sufficient for whatever reason, contact me directly and I'll try to find some way for having some special testing branch created for you or so.

(0002677)
psmedley   
2014-02-16 19:47   
I can reproduce this with 1.7.14

Tryibg to work out what's gone wrong.

Now that 1.7 works with netlabs I can easily reproduce
(0002679)
psmedley   
2014-02-21 19:21   
translate-test.exe fails dismally - still working through why
(0002681)
xhajt03   
2014-02-25 07:16   
I'm glad that you found some time for having a look at it and look forward to future news. :-)

BTW, the notifications from this site are a complete mystery. This is the first time ever when I got any notification from one of bugs in this Mantis instance. However, I didn't get any notification after the update on the 16th, and even now the notification was only sent after the bug report became monitored by Steven Levine apparently rather than after the last note added... :/
(0002682)
psmedley   
2014-02-25 18:48   
looks like APR (Apache Portable Runtime) is inserting CRLF all the time, might be time to replace the file_io code with the unix code, with the added benefits that symlinks should be handled better.
(0002687)
psmedley   
2014-03-10 19:14   
http://smedley.id.au/tmp/subversion-1.7.16-os2-20140310.zip
(0002701)
xhajt03   
2014-03-17 18:20   
Again, no notification arrived, but it didn't take that much time since the last note... I'll check this build tonight or tomorrow and let you know the results.
(0002702)
psmedley   
2014-03-17 18:34   
Notifications work for me - is it possible they go to your spam folder?
(0002705)
xhajt03   
2014-03-19 19:07   
Nope, it cannot be due to a spam folder (among other reasons like that I checked the spam folder, I'd consider the fact that I _did_ receive a notification from here once, although triggered by a different / strange event, as a sufficient proof that the spam filter is innocent).

Do you have access to the log of SMTP server configured in Mantis? If yes, do you see any notifications on this report (explicitly monitored by me) going to my address? Or possibly if mantis logs the sent notifications, do you see them in its own log?

I believe that Mantis allows general configuration for notifications for the whole instance which might be one possible reason why notifications work for you (assuming that you opted to be notified e.g. for all new reports rather than only the monitored ones).

BTW, sorry, I haven't checked the svn build yet, but obviously will do so as soon as possible.
(0002706)
Steven Levine   
2014-03-20 06:27   
FYI, since I was validating the xwp cvs2svn conversion, I took the opportunity to gave 1.7.16 a try. The svn diff problem seems to have been resolved based on what I can see. This is with the repo configured with svn:eol-style=CRLF at the request of the main xwp maintainer.

Regarding the lack of notifications, is there a possibility that something has happened to your mantis profile that caused notifications to be turned off? See

  http://mantis.smedley.id.au/account_prefs_page.php
(0002707)
xhajt03   
2014-03-21 08:32   
First of all, I can confirm that the svn diff problem is gone with the latest build - many thanks, Paul!

Regarding the notifications - correct me if I'm wrong, but all the preferences seen on that page refer to general notifications for _all_ tickets meeting the defined conditions (i.e. if someone wants to be notified about all new tickets, he can tick the respective option). I don't see any option related to events related to tickets monitored by me on that page and I also don't think that such an option would make much sense - if someone starts monitoring a particular ticket, he explicitly asks for monitoring this particular ticket and no special configuration option should be necessary for that. Again, if this is all due to my wrong understanding and all these options refer _only_ to monitored tickets, then indeed my configuration is wrong and it's just my own fault.
(0002708)
Steven Levine   
2014-03-21 09:51   
Not quite. The email preferences determine if you stay in the list of potential recipients. What the state of a ticket changes, Mantis builds a list of potential recipient composed of the system default recipients, the users that have contributed to the ticket and the users that have asked to monitor the ticket. Once the list is assembled, Mantis checks each user and removes the user from the list based on the event type and the user's account preferences. In this sense, the Account Preferences are secondary.

Mantis does not force anyone of receive e-mail. If you uncheck all the email preferences, Mantis assumes you want to do everything via the web interface. Based on what you have said, I suspect you have unchecked preferences that you should have left checked.

BTW, since you are the reporter, there's no need for you to also monitor the ticket. The reporter is also included in the potential recipient list.
(0002709)
psmedley   
2014-03-21 10:20   
Probably the most interesting part, is that xhatj03 states they are *sometimes* receiving notifications but not always. I will try find time tomorrow to review postfix logs and see if there's anything in there in terms of errors sending mail.
(0002710)
xhajt03   
2014-03-21 18:39   
Thanks for the explanation - in this light, my configuration has been indeed wrong. :-( Sorry for the confusion. :-(((

Regarding reports and monitoring - yes, I know that I shouldn't need monitoring as a reporter, but since it hasn't worked for me previously, I wanted to try monitoring as an explicit request (rather than relying on an expected implicit behaviour)...

I guess that checking Postfix logs is not really necessary any longer (if you want and if you keep logs for sufficiently long, you'd probably find a record about an e-mail sent from Mantis on 25 Feb 2014 03:06:52 +1030 (CST) (quoting from the received header). I guess that the most likely reason (again, based on the Steven's explanation above) why that notification was delivered would be that the Preferences page contains no negative filter for the monitored event became monitored also by someone else (in this case Steven).

Anyway, thanks to both of you for resolution of both issues (although the second one was apparently between the chair and desk :/ ).
(0002711)
psmedley   
2014-03-21 18:49   
Yep I did just find a log entry from 25 Feb :) Glad it's resolved now!
(0002712)
psmedley   
2014-03-21 18:49   
I believe this is fixed in latest 1.7.x build :)

Issue History
2012-04-16 08:38xhajt03New Issue
2012-10-04 06:05psmedleyNote Added: 0002324
2013-07-29 01:24maazlFile Added: diff
2013-07-29 01:34maazlNote Added: 0002461
2013-07-29 03:48maazlNote Added: 0002462
2013-07-29 03:49maazlNote Edited: 0002462bug_revision_view_page.php?bugnote_id=2462#r81
2013-10-21 07:34xhajt03Note Added: 0002569
2013-10-21 07:38xhajt03Note Edited: 0002569bug_revision_view_page.php?bugnote_id=2569#r98
2014-02-16 19:47psmedleyNote Added: 0002677
2014-02-21 19:21psmedleyNote Added: 0002679
2014-02-25 07:16xhajt03Note Added: 0002681
2014-02-25 18:48psmedleyNote Added: 0002682
2014-03-10 19:14psmedleyNote Added: 0002687
2014-03-10 19:14psmedleyAssigned To => psmedley
2014-03-10 19:14psmedleyStatusnew => feedback
2014-03-17 18:20xhajt03Note Added: 0002701
2014-03-17 18:20xhajt03Statusfeedback => assigned
2014-03-17 18:34psmedleyNote Added: 0002702
2014-03-19 19:07xhajt03Note Added: 0002705
2014-03-20 06:27Steven LevineNote Added: 0002706
2014-03-21 08:32xhajt03Note Added: 0002707
2014-03-21 09:51Steven LevineNote Added: 0002708
2014-03-21 10:20psmedleyNote Added: 0002709
2014-03-21 18:39xhajt03Note Added: 0002710
2014-03-21 18:49psmedleyNote Added: 0002711
2014-03-21 18:49psmedleyNote Added: 0002712
2014-03-21 18:49psmedleyStatusassigned => resolved
2014-03-21 18:49psmedleyResolutionopen => fixed