View Issue Details

IDProjectCategoryView StatusLast Update
0000534Subversion for OS/2 & eCSBugpublic2020-08-24 03:07
Reporterxhajt03 Assigned Topsmedley  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
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 bytes)   
Index: docking.h
===================================================================
--- docking.h	(revision 1201)
+++ docking.h	(working copy)
@@ -1,82 +1,84 @@
-/*
- * Copyright 2006 Dmitry A.Steklenev <glass@ptv.ru>
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
- *
- *    1. Redistributions of source code must retain the above copyright notice,
- *       this list of conditions and the following disclaimer.
- *
- *    2. Redistributions in binary form must reproduce the above copyright
- *       notice, this list of conditions and the following disclaimer in the
- *       documentation and/or other materials provided with the distribution.
- *
- *    3. The name of the author may not be used to endorse or promote products
- *       derived from this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
- * EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
- * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
- * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
- * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
- * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
 
-#ifndef PM123_DOCKING_H
-#define PM123_DOCKING_H
 
-#ifdef __cplusplus
-extern "C" {
-#endif
 
-#define DK_MAX_DOCKED 32      /* The maximum of the used dockable windows.  */
-#define DK_IS_MASTER  0x0001  /* Is the master window.                      */
-#define DK_IS_GHOST   0x0002  /* Is the invisible window.                   */
-#define DK_IS_DOCKED  0x0004  /* Is the docked window.                      */
-#define DK_IS_PULLED  0x0008  /* Is the window already pulled by his owner. */
 
-#define UM_DOCKWINDOW (WM_USER+737)
 
-typedef struct _DK_DATA {
 
-  HWND   hwnd;
-  PFNWP  def_proc;
-  int    state;
 
-  struct _DK_DATA* childs[DK_MAX_DOCKED];
-  struct _DK_DATA* owners[DK_MAX_DOCKED];
 
-  int    childs_count;
-  int    owners_count;
 
-} DK_DATA, *PDK_DATA;
 
-/** Adds a specified window to the docking subsystem. */
-BOOL dk_add_window( HWND hwnd, int state );
-/** Removes a specified window from the docking subsystem. */
-BOOL dk_remove_window( HWND hwnd );
-/** Returns a state of the specified window. */
-int  dk_get_state( HWND hwnd );
-/** Sets a state of the specified window. */
-void dk_set_state( HWND hwnd, int state );
 
-/* Rebuilds all relationships with the specified window. */
-void dk_arrange( HWND hwnd );
-/* Cleanups all relationships with the specified window. */
-void dk_cleanup( HWND hwnd );
 
-/** Initializes of the docking subsystem. */
-void dk_init( void );
-/** Terminates of the docking subsystem. */
-void dk_term( void );
 
-#ifdef __cplusplus
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 }
-#endif
-#endif /* PM123_DOCKING_H */
 
 
+
+
+
+/* * Copyright 2006 Dmitry A.Steklenev <glass@ptv.ru> * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are met: * *    1. Redistributions of source code must retain the above copyright notice, *       this list of conditions and the following disclaimer. * *    2. Redistributions in binary form must reproduce the above copyright *       notice, this list of conditions and the following disclaimer in the *       documentation and/or other materials provided with the distribution. * *    3. The name of the author may not be used to endorse or promote products *       derived from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO * EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */#ifndef PM123_DOCKING_H#define PM123_DOCKING_H#ifdef __cplusplusextern "C" {#endif#define DK_MAX_DOCKED 32      /* The maximum of the used dockable windows.  */#define DK_IS_MASTER  0x0001  /* Is the master window.                      */#define DK_IS_GHOST   0x0002  /* Is the invisible window.                   */#define DK_IS_DOCKED  0x0004  /* Is the docked window.                      */#define DK_IS_PULLED  0x0008  /* Is the window already pulled by his owner. */#define UM_DOCKWINDOW (WM_USER+737)typedef struct _DK_DATA {  HWND   hwnd;  PFNWP  def_proc;  int    state;  struct _DK_DATA* childs[DK_MAX_DOCKED];  struct _DK_DATA* owners[DK_MAX_DOCKED];  int    childs_count;  int    owners_count;} DK_DATA, *PDK_DATA;/** Adds a specified window to the docking subsystem. */BOOL dk_add_window( HWND hwnd, int state );/** Removes a specified window from the docking subsystem. */BOOL dk_remove_window( HWND hwnd );/** Returns a state of the specified window. */int  dk_get_state( HWND hwnd );/** Sets a state of the specified window. */void dk_set_state( HWND hwnd, int state );/* Rebuilds all relationships with the specified window. */void dk_arrange( HWND hwnd );/* Cleanups all relationships with the specified window. */void dk_cleanup( HWND hwnd );/** Initializes of the docking subsystem. */void dk_init( void );/** Terminates of the docking subsystem. */void dk_term( void );#ifdef __cplusplus#endif#endif /* PM123_DOCKING_H */
\ No newline at end of file
diff (6,453 bytes)   

Activities

psmedley

2012-10-03 20:35

administrator   ~0002324

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?

maazl

2013-07-28 16:04

reporter   ~0002461

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.

maazl

2013-07-28 18:18

reporter   ~0002462

Last edited: 2013-07-28 18:19

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.

xhajt03

2013-10-20 21:04

reporter   ~0002569

Last edited: 2013-10-20 21:08

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.

psmedley

2014-02-16 09:17

administrator   ~0002677

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

psmedley

2014-02-21 08:51

administrator   ~0002679

translate-test.exe fails dismally - still working through why

xhajt03

2014-02-24 20:46

reporter   ~0002681

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... :/

psmedley

2014-02-25 08:18

administrator   ~0002682

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.

psmedley

2014-03-10 08:44

administrator   ~0002687

http://smedley.id.au/tmp/subversion-1.7.16-os2-20140310.zip

xhajt03

2014-03-17 07:50

reporter   ~0002701

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.

psmedley

2014-03-17 08:04

administrator   ~0002702

Notifications work for me - is it possible they go to your spam folder?

xhajt03

2014-03-19 08:37

reporter   ~0002705

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.

Steven Levine

2014-03-19 19:57

manager   ~0002706

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

xhajt03

2014-03-20 22:02

reporter   ~0002707

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.

Steven Levine

2014-03-20 23:21

manager   ~0002708

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.

psmedley

2014-03-20 23:50

administrator   ~0002709

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.

xhajt03

2014-03-21 08:09

reporter   ~0002710

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 :/ ).

psmedley

2014-03-21 08:19

administrator   ~0002711

Yep I did just find a log entry from 25 Feb :) Glad it's resolved now!

psmedley

2014-03-21 08:19

administrator   ~0002712

I believe this is fixed in latest 1.7.x build :)

Issue History

Date Modified Username Field Change
2012-04-15 23:08 xhajt03 New Issue
2012-10-03 20:35 psmedley Note Added: 0002324
2013-07-28 15:54 maazl File Added: diff
2013-07-28 16:04 maazl Note Added: 0002461
2013-07-28 18:18 maazl Note Added: 0002462
2013-07-28 18:19 maazl Note Edited: 0002462
2013-10-20 21:04 xhajt03 Note Added: 0002569
2013-10-20 21:08 xhajt03 Note Edited: 0002569
2014-02-16 09:17 psmedley Note Added: 0002677
2014-02-21 08:51 psmedley Note Added: 0002679
2014-02-24 20:46 xhajt03 Note Added: 0002681
2014-02-25 08:18 psmedley Note Added: 0002682
2014-03-10 08:44 psmedley Note Added: 0002687
2014-03-10 08:44 psmedley Assigned To => psmedley
2014-03-10 08:44 psmedley Status new => feedback
2014-03-17 07:50 xhajt03 Note Added: 0002701
2014-03-17 07:50 xhajt03 Status feedback => assigned
2014-03-17 08:04 psmedley Note Added: 0002702
2014-03-19 08:37 xhajt03 Note Added: 0002705
2014-03-19 19:57 Steven Levine Note Added: 0002706
2014-03-20 22:02 xhajt03 Note Added: 0002707
2014-03-20 23:21 Steven Levine Note Added: 0002708
2014-03-20 23:50 psmedley Note Added: 0002709
2014-03-21 08:09 xhajt03 Note Added: 0002710
2014-03-21 08:19 psmedley Note Added: 0002711
2014-03-21 08:19 psmedley Note Added: 0002712
2014-03-21 08:19 psmedley Status assigned => resolved
2014-03-21 08:19 psmedley Resolution open => fixed
2020-08-24 03:07 psmedley Status resolved => closed