You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ryan Schmidt <su...@ryandesign.com> on 2013/09/01 00:20:42 UTC
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
> Sending iTextSharp.xml
> Sending itextsharp.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.
If you do not set svn:eol-style, then Subversion does not check the line endings and lets you commit whatever you want, so if for some reason you want inconsistent line endings then that's how you can have that.
> Question 2: Why txn-protorevs aren’t being cleaned up properly?
I don't know what's going on there. Do you have any hook scripts? Maybe one of them is programmed incorrectly.
RE: SVN commit line ending handling
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2012c@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
> > Sending iTextSharp.xml
> > Sending itextsharp.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
RE: SVN commit line ending handling
Posted by Geoff Field <Ge...@aapl.com.au>.
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.
Re: SVN commit line ending handling
Posted by Thorsten Schöning <ts...@am-soft.de>.
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.Schoening@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: SVN commit line ending handling
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: Ryan Schmidt
> Sent: Sunday, 1 September 2013 8:21 AM
> 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
> > Sending iTextSharp.xml
> > Sending itextsharp.dll
> > Transmitting file data ..
> > svn: E135000: Commit failed (details follow):
> > svn: E135000: While preparing 'iTextSharp.xml' for commit
> > svn: E135000: Inconsistent line ending style
I've seen this a few times when committing an auto-generated XML file - mostly because it was encoded as UTF-16.
> > 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.
Since I've been using the TortoiseSVN client, I haven't noticed whether these additional errors popped up as well.
> > 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.
I was going to ask "why not?" However, I realised this is because the SVN philosophy is to not change files unless explicitly requested to (with keywords).
> If you do not set svn:eol-style, then Subversion does not
> check the line endings and lets you commit whatever you want,
> so if for some reason you want inconsistent line endings then
> that's how you can have that.
If the file's encoded as UTF-16, it will give this error regardless of the consistency of the line endings. I've found the easiest way around this (for me) is to copy and paste the contents of the XML file into a new file encoded as UTF-8, then save it over the top of the original file. Notepad++ is my preferred option for this at the moment, but any text editor should do the job.
> > Question 2: Why txn-protorevs aren't being cleaned up properly?
>
> I don't know what's going on there. Do you have any hook
> scripts? Maybe one of them is programmed incorrectly.
Regards,
Geoff
- 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.