View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000534 | Subversion for OS/2 & eCS | Bug | public | 2012-04-15 23:08 | 2020-08-24 03:07 |
Reporter | xhajt03 | Assigned To | psmedley | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | I386 | OS | eCS | OS Version | 1.0 (last FP) |
Summary | 0000534: SVN commands diff and merge broken | ||||
Description | I 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 Reproduce | Let'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 Information | SVN version 1.7.4 built on the 12th of March 2012 (subversion-1.7.4-os2-20120312.zip). | ||||
Tags | No 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 | ||||
|
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? |
|
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. |
|
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. |
|
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. |
|
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 |
|
translate-test.exe fails dismally - still working through why |
|
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... :/ |
|
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. |
|
http://smedley.id.au/tmp/subversion-1.7.16-os2-20140310.zip |
|
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. |
|
Notifications work for me - is it possible they go to your spam folder? |
|
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. |
|
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 |
|
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. |
|
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. |
|
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. |
|
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 :/ ). |
|
Yep I did just find a log entry from 25 Feb :) Glad it's resolved now! |
|
I believe this is fixed in latest 1.7.x build :) |
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 |