Re: SVN commit line ending handling
Guten Tag Geoff Field, am Montag, 2. September 2013 um 01:09 schrieben Sie: If the file's encoded as UTF-16, it will give this error regardless of the consistency of the line endings. I successfully committed UTF-16 some minutes ago, Subversion doesn't care about the character set of the files. The problem in your case surely was because of inconsistent line endings as well. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Planning a SVN upgrade
On 23/08/13 21:09, Maureen Barger wrote: Hi - I am currently planning an upgrade from SVN 1.5 (using svnserve and ssh tunnel) to SVN 1.8.1 fronted with Apache and webdav using AD for authNz. We have about 50 repos. I'll be moving from an older Ubuntu 8 install to Centos 6 x64. My thought was I could upgrade the SVN installation in place, bringing the repo up to 1.8 and then dump those repos and bring them online in the new environment. We currently use Eclipse as our IDE and Jenkins as our CI tool with Nexus as the object repo. I was thinking to leave the upgrade of Eclipse client and svnkit to the indiviidual so they can decide what direction to take with their working copies et al. I do not foresee any changes I would need to make to Jenkins or Nexus. Has anyone made a jump this large before? Any comments about my upgrade plan? Thanks! Being a totally new server, may I suggest using svnsync instead of a dump/load cycle? It's very easy to set up, you can still use the old repositories while syncing and if you take care of using the same UUID on the new repository you might even be able to make the switch completely transparent to the clients. I did an upgrade about three years ago, I think from 1.4 to 1.6, and I used svnsync. It worked very well. I don't share others' concerns about not upgrading the repository (which will happen if you use svnsync). I don't see why now. Besides, using svnsync, you don't touch the old repositories at all so you still have the old format repos if you need them. Just my 2p
RE: SVN commit line ending handling
-Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: zondag 1 september 2013 0:21 To: Edoardo Pinci Cc: users@subversion.apache.org Subject: Re: SVN commit line ending handling On Aug 31, 2013, at 05:29, Edoardo Pinci wrote: I periodically receive this kind of errors since a long time. X:\svn commit -m BLA BLA itextsharp.dll iTextSharp.xml SendingiTextSharp.xml Sendingitextsharp.dll Transmitting file data .. svn: E135000: Commit failed (details follow): svn: E135000: While preparing 'iTextSharp.xml' for commit svn: E135000: Inconsistent line ending style svn: E720032: Additional errors: svn: E720032: Transaction '1718-1ca' cleanup failed svn: E720032: Can't remove file 'Depot\db\txn-protorevs\1718-1ca.rev': The process cannot access the file because it is being used by another process. Question 1: Is there a way to have SVN normalize line ending on commit by itself? It seems svn:eol-style is set on this file. If you set svn:eol-style on a file (to any supported value), Subversion requires that the file have consistent line endings before you commit it. You or your tools must do this; Subversion will not. Not only that: Subversion also assumes that your file is ascii-like text e.g. UTF-8. UTF-16 (or UCS-2) doesn't work in that context as it usually has a lot of '\0' bytes and a bytewise completely different eol marker. Bert
Crash during sync after automatic merges
Hello, When SVN 1.8.0 was released, I started using automatic merges for one of my branches. It worked fine. I updated to 1.8.1 and at some point I wanted to do a sync-merge again. Now SVN crashed. I'm using Tortoise-SVN so, I went to the console version from cygwin and tried the same command. It also crashed with console SVN. I downgraded to SVN 1.8.0 - still crashing. I now upgraded to 1.8.3 and still have the crash. Is there any known issue regarding automatic merges, that leads to a crash? See the content of the .stackdump file from console-svn below this mail. The issue is reproducible every time I start the sync: svn merge ^/trunk There is also the automatically uploaded dump from tortoise if that helps in any way: https://www.crash-server.com/DumpGroup.aspx?ClientID=tsvnLogin=GuestDumpGroupID=88264 Regards, Ruben Exception: STATUS_ACCESS_VIOLATION at eip=6A234F2E eax= ebx=8046DE88 ecx=00289F9C edx= esi=0001 edi=804D61A2 ebp=0028A03C esp=00289FE0 program=C:\cygwin\bin\svn.exe, pid 9268, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 0028A03C 6A234F2E (, 000A, 804D5DD8, 80499338) End of stack trace
libsvn_ra_serf/util.c: undefined reference to serf_bucket_request_set_CL [1.8.1][1.8.3][WORKAROUND]
I am mailing this just to make the workaround known to other users. When compiling subversion 1.8.1 or 1.8.3 from apache's source package, configure --with-serf=/usr/local/serf is not enough to use a specific serf version. Not if another version was installed as debian packages. Workaround: Uninstall the debian packages, then do make install again. Symptom: make install fails with: cd subversion/libsvn_ra_serf ; [...] libtool: install: warning: relinking `libsvn_ra_serf-1.la' [...] .libs/util.o: In function `setup_serf_req': [...]/subversion-1.8.3/subversion/libsvn_ra_serf/util.c:760: undefined reference to `serf_bucket_request_set_CL' [...]/subversion-1.8.3/subversion/libsvn_ra_serf/util.c:758: undefined reference to `serf_bucket_request_set_CL' collect2: ld returned 1 exit status libtool: install: error: relink `libsvn_ra_serf-1.la' with the above command before installing it make: *** [install-serf-lib] Fehler 1 (Fehler is German for Error) Tested with Ubuntu 12.04 x64 and the distribution's standart libserf1 and libserf-dev packages. Klaus Thorn IT Administrator klaus.th...@noumenastudios.com Noumena Studios GmbH part of kalypso media group Lützowstraße 33 10785 Berlin Germany http://www.noumenastudios.com http://www.kalypsomedia.com CEO/Geschäftsführer: Stefan Marcinek Commercial register of the local court / Registergericht: HRB 129507 B VAT identification number / Ust-Id.Nr.: DE274058087 This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. Noumena Studios is unable to control the content transmitted via the Internet. Noumena Studios hereby excludes any written or implied warranty as to the accuracy of any information contained in this message and any liability of any kind for the information contained, therein, or for its transmission, reception, storage or usage in any way
RE: SVN commit line ending handling
Hi Thorsten, Guten Tag Geoff Field, am Montag, 2. September 2013 um 01:09 schrieben Sie: If the file's encoded as UTF-16, it will give this error regardless of the consistency of the line endings. I successfully committed UTF-16 some minutes ago, Subversion doesn't care about the character set of the files. Last time I did a commit of this file, I was using TortoiseSVN version 1.7.13 (or earlier) on a Windows system. The properties include svn:eol-style=native and svn:mime-type=text/xml (this latter is probably from autoprops). The problem in your case surely was because of inconsistent line endings as well. It's possible. I did look at the file with a hex editor to try to fix things, but didn't see any inconsistent line endings. Of course, this does not mean there were none, just that I didn't see them. In the hex editor, the line endings were all encoded as 00 0d 00 0a. Given the native eol style, I think SVN might have been looking for 0d 0a without the padding. SVN might even have seen the 00 0d as one line ending and the 00 0a as the next. Since the file is auto-generated as part of an installation package, one would hope the auto-generation tool would make the endings consistent. However, hope is no substitute for reality. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
