'svnadmin verify' failed after hotcopy with 'svnadmin: E160004: Revision file (r2255) lacks trailing newline'
Hi, My svn backup script calls: - svnadmin hotcopy - svnadmin verify (on the copy) Once (for now) the verify call failed with 'svnadmin: E160004: Revision file (r2255) lacks trailing newline' The copy of the repository is still available and I can reproduce the problem. The subsequent hot copies of the same repository are ok (for now). Is it ok to file this as a hotcopy bug, please? The server is VisualSVN 2.5.2 (Subversion 1.7.2) on WinXP SP3. Thanks, Dmitry
Re: 'svnadmin verify' failed after hotcopy with 'svnadmin: E160004: Revision file (r2255) lacks trailing newline'
Daniel, Is your answer based on the knowledge of the code of the subversion server? Here are some details: 1. It is not Unix [cp(1)], the problem was on Windows 2. The disk looks fine (I ran chkdsk and looked at the SMART data). No errors in the Windows log files. 3. The svn repository did not change since the problem was detected and I compared the corrupt hot copy to a correct one. There are 7940 files in each. Of these, the contents of 28 files are not the same (file sizes are ok). These 28 files are of various sizes but the first one (2255) is rather large - 1.5 MB. The repository size is about 1GB. The data in the rev files of the bad copy is corrupted from positions 0x1000 (first and second file), 0x4000, 0, 0x1000, 0, 0, 0x4000, 0, 0, 0, 0x4000 etc. The corrupted file numbers are not sequential (2255 corrupted, 2256-2270 ok, 2271 corrupted). 4. Some antivirus software is running on the system. 5. The 'svnadmin hotcopy' which produced the corrupt copy returned 0 (success) to the script that called it. 6. The system might have been heavily loaded at the time the corrupt copy was made. It looks unlikely that 28 files were corrupted and no errors were logged by the OS. Do you still think is was a disk issue? Thanks, Dmitry PS The server is VisualSVN 2.5.2 (Subversion 1.7.2) on WinXP SP3. On Wed, Jan 11, 2012 at 6:52 PM, Daniel Shahaf wrote: > D D wrote on Wed, Jan 11, 2012 at 15:51:32 +0400: > > Once (for now) the verify call failed with 'svnadmin: E160004: Revision > > file (r2255) lacks trailing newline' > > The copy of the repository is still available and I can reproduce the > > problem. > > The subsequent hot copies of the same repository are ok (for now). > > > > Is it ok to file this as a hotcopy bug, please? > > > > No. All 'hotcopy' does is copy the revisions files using the same means > cp(1) uses. I'd check the health of your disks or replace them. >
Re: 'svnadmin verify' failed after hotcopy with 'svnadmin: E160004: Revision file (r2255) lacks trailing newline'
On Thu, Jan 12, 2012 at 3:41 PM, Andy Levy wrote: > Have you run svnadmin verify against the *actual* repository? Yes. No problem detected. > If you make a new hotcopy of the repository, is that corrupted as well? > No. I've only got a corrupted hot copy once in the last two weeks (backups are daily). Before that the repository was hosted on another WinXP system with an earlier version of the Subversion server. I only added the call to verify the hot copy to the backup script recently so I do not know if the problem ever occurred with the repository on the other system. I'd be interested to know if svnadmin employs some memory buffer to hot-copy. The offsets where data corruption starts look like multiples of 0x1000 which is 4K. The NTFS cluster size on the disk is exactly 4K. If svnadmin just calls the OS to copy each file the problem should either be in the OS or the disk.
mime/confusing checkout error
Odd issues after converting to subversion. Binary files that have only one revision seem to be giving us checkin/checkout problems. I can use Tortoise SVN to "Open" the files, and they display fine. I can "save as" from the web front end, and the files are fine. however, when I check the files out, they are broken, corrupted, or give "inconsistent line ending style" (tortoise). What is even weirder is that I can check out the broken files, save a good version over the top of the broke files, commit the non-broken version, and it still ends up broken when I try to check out again. I've tried manually setting the mimetype properties, and that hasnt worked. i'm basically at a loss on how I can make these "right". Any suggestions on things I can check? tia, d
Re: mime/confusing checkout error
On Fri, Nov 12, 2010 at 12:21 PM, Ryan Schmidt < subversion-20...@ryandesign.com> wrote: > > On Nov 12, 2010, at 09:57, d wrote: > > > Binary files that have only one revision seem to be giving us > checkin/checkout problems. I can use Tortoise SVN to "Open" the files, and > they display fine. I can "save as" from the web front end, and the files > are fine. > > > > however, when I check the files out, they are broken, corrupted, or give > "inconsistent line ending style" (tortoise). > > If they're binary, there shouldn't be anything looking at their line ending > style. Line ending style is a concept applicable only to text files. I > suspect you have asked Subversion to corrupt these files by setting the > "svn:eol-style" property to some value on these files. So you should delete > that property from these files, then replace them with good copies of the > files. Don't set svn:eol-style on binary files. > > Thanks so much Ryan. Removing the svn:eol-style prop and reseeding the files worked great.
Vendor branches: Current guidance?
Hello all, What are the currently accepted best practices / tools for maintaining "vendor" branches? I've seen the page at:http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html I ask about updated guidance since: 1) I notice some (?) churn for this section in the SVN Book repository:https://code.google.com/p/svnbook/source/browse/trunk/en/book/ch04-branching-and-merging.xml 2) There appears to be both "svn_load_dirs" and "svn-merge-vendor.py" scripts at:http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/ I'm trying to refactor out some thirdparty code from my codebase, and I'd like to set things up correctly. (I'd hate to screw things up just because I accidentally read a soon-to-be-outdated HOWTO.) Secondarily, what kind of issues can I expect to encounter as I setup and use a vendor branch style deployment? Thank you,David
RE: Vendor branches: Current guidance? [Fixed formatting]
Hello all, [Repost with formatting fixed. Misbehaving email client. ] What are the currently accepted best practices / tools for maintaining "vendor" branches? Particularly where maintaining patches against vendor drops is expected. I've seen the page at: http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html I ask about updated guidance since: 1) I notice some (?) churn for this section in the SVN Book repository: https://code.google.com/p/svnbook/source/browse/trunk/en/book/ch04-branching-and-merging.xml 2) There appears to be both "svn_load_dirs" and "svn-merge-vendor.py" scripts at: http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/ I'm trying to refactor out some thirdparty code from my codebase, and I'd like to set things up correctly. (I'd hate to screw things up just because I accidentally read a soon-to-be-outdated HOWTO.) Secondarily, what kind of issues can I expect to encounter as I setup and use a vendor branch style deployment? Thank you, David
Require better support for Tags, Branches, and Merge operations in Subversion when using svn:externals
Hi, When using Subversion with a large project that integrates multiple independent libraries and modules that come from different SVN repositories, it is necessary to use the svn:external mechanism to link to the different modules in subversion. However there are several problems with using externals when active development is also going on within the referenced module. Summary: 1) References must be individually managed with "svn propedit" 2) References should be pinned to specific versions when tagging. 3) Tagging should result in a tag being created in the referenced repository 4) Branching should result in a tag being created in the referenced repository 5) Commits should be recursive 6) Merges should be recursive Please help us to solve this at the earliest. Thanks & Regards, Dinoj D Desk: +91 80 26588360 Extn: 48547 Cell: +91 9916668051
SVN Update is not happening from the server, though the status shows "Completed"
Hi, One of my team members made few changes to existing files in SVN. When I performed SVN update, status shown is "Completed : " But actually the files are not updated when checked for the changes. I tried to perform SVN clean and update, even then it is the same. When I deleted the files and then performed update I now saw the changes made are reflecting properly. But I cannot delete the files and do SVN update every time I want to see the updated files as it is a time consuming activity. This issue is seen for the first time in my machine. Please help us Thanks & Regards, Dinoj D Desk: +91 80 26588360 Extn: 48547 Cell: +91 9916668051
RE: SVN Update is not happening from the server, though the status shows "Completed"
Hi Bib The version is .6.9 (r901367) It is happening with new check out, but for one specific path. Thanks & Regards, Dinoj D Desk: +91 80 26588360 Extn: 48547 Cell: +91 9916668051 -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Wednesday, April 27, 2011 7:48 PM To: D, Dinoj; users@subversion.apache.org Subject: RE: SVN Update is not happening from the server, though the status shows "Completed" > One of my team members made few changes to existing files in SVN. > When I performed SVN update, status shown is "Completed : > " > But actually the files are not updated when checked for the > changes. > I tried to perform SVN clean and update, even then it is the same. > > When I deleted the files and then performed update I now saw the > changes made are reflecting properly. > > But I cannot delete the files and do SVN update every time I want > to see the updated files as it is a time consuming activity. > > This issue is seen for the first time in my machine. Please help us What version of svn? Is this still happening with the new checkout? It is possible you had a sparse checkout so you weren't getting the new files. I think there was an older version that had a bug which would label a checked out folder as immediate rather than full depth giving you a sparse checkout. BOb
RE: SVN Update is not happening from the server, though the status shows "Completed"
It is working with new working copy. Could you please let me know what are the main reasons behind this issue and how to avoid this not to come in future. Thanks & Regards, Dinoj D Desk: +91 80 26588360 Extn: 48547 Cell: +91 9916668051 -Original Message- From: Bob Archer [mailto:bob.arc...@amsi.com] Sent: Wednesday, April 27, 2011 7:48 PM To: D, Dinoj; users@subversion.apache.org Subject: RE: SVN Update is not happening from the server, though the status shows "Completed" > One of my team members made few changes to existing files in SVN. > When I performed SVN update, status shown is "Completed : > " > But actually the files are not updated when checked for the > changes. > I tried to perform SVN clean and update, even then it is the same. > > When I deleted the files and then performed update I now saw the > changes made are reflecting properly. > > But I cannot delete the files and do SVN update every time I want > to see the updated files as it is a time consuming activity. > > This issue is seen for the first time in my machine. Please help us What version of svn? Is this still happening with the new checkout? It is possible you had a sparse checkout so you weren't getting the new files. I think there was an older version that had a bug which would label a checked out folder as immediate rather than full depth giving you a sparse checkout. BOb
RE: SVN Update is not happening from the server, though the status shows "Completed"
I don't think , it was of my mistake. I didn't set anything special to the working , simply adding, committing and updating the working copy. And also the interface I am using for the SVN operation is Tortoise SVN with default settings. If you are saying it was because of "--depth", what would be the fix without altering anything on the Working copy, recreating of working is not a good solution if the data is in huge amount. Thanks & Regards, Dinoj D Desk: +91 80 26588360 Extn: 48547 Cell: +91 9916668051 -Original Message- From: Stephen Butler [mailto:sbut...@elego.de] Sent: Wednesday, May 04, 2011 4:54 PM To: D, Dinoj Cc: Bob Archer; users@subversion.apache.org; Cheruvathoor, Anoop(IE10) Subject: Re: SVN Update is not happening from the server, though the status shows "Completed" On May 4, 2011, at 12:57 , D, Dinoj wrote: > It is working with new working copy. Could you please let me know what > are the main reasons behind this issue and how to avoid this not to come > in future. As Bob Archer mentioned below, the 'svn update --depth' command is buggy. http://subversion.tigris.org/issues/show_bug.cgi?id=3569 " svn update --depth allows making a working copy incomplete" The issue is still open. Of course, we're just guessing that this issue is related to your problem. You didn't mention what you did in the working copy before the problem occurred. Was the --depth option used at all? Can you reproduce the problem in a fresh working copy? If so, please provide the list of commands that cause the problem. Steve > > Thanks & Regards, > Dinoj D > Desk: +91 80 26588360 Extn: 48547 > Cell: +91 9916668051 > -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Wednesday, April 27, 2011 7:48 PM > To: D, Dinoj; users@subversion.apache.org > Subject: RE: SVN Update is not happening from the server, though the > status shows "Completed" > >> One of my team members made few changes to existing files in SVN. >> When I performed SVN update, status shown is "Completed : >> " >> But actually the files are not updated when checked for the >> changes. >> I tried to perform SVN clean and update, even then it is the same. >> >> When I deleted the files and then performed update I now saw the >> changes made are reflecting properly. >> >> But I cannot delete the files and do SVN update every time I want >> to see the updated files as it is a time consuming activity. >> >> This issue is seen for the first time in my machine. Please help us > > What version of svn? > > Is this still happening with the new checkout? > > It is possible you had a sparse checkout so you weren't getting the new > files. I think there was an older version that had a bug which would > label a checked out folder as immediate rather than full depth giving > you a sparse checkout. > > BOb > -- Stephen Butler | Senior Consultant elego Software Solutions GmbH Gustav-Meyer-Allee 25 | 13355 Berlin | Germany tel: +49 30 2345 8696 | mobile: +49 163 25 45 015 fax: +49 30 2345 8695 | http://www.elegosoft.com Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
SVN files content Type
Hi, All the "content Types" are set for our apache server. This is working well for local apache paths . But if we point this to subversion , it wouldn't work. Could you please let me know how to set content type for subversions as well Thanks & Regards, Dinoj D Desk: +91 80 26588360 Extn: 48547 Cell: +91 9916668051
RE: SVN files content Type
Hi Ryan Can we make it possible to contact apache content type using any modules..Setting the svn:mime-type to all individual files is not a good solution Thanks & Regards, Dinoj D Desk: +91 80 26588360 Extn: 48547 Cell: +91 9916668051 -Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Tuesday, May 10, 2011 11:52 AM To: D, Dinoj Cc: users@subversion.apache.org Subject: Re: SVN files content Type On May 9, 2011, at 23:51, D, Dinoj wrote: > All the "content Types" are set for our apache server. This is working well for local apache paths . But if we point this to subversion , it wouldn't work. Could you please let me know how to set content type for subversions as well For each individual file in the repository, you must set the svn:mime-type property. Subversion does not use your Apache content types.
RE: SVN files content Type
Hi Ryan Thanks for your prompt response. The content type should be worked only while accessing the files through web browser.The problem here we are facing is that while accessing the files through web browser the extensions .docx, .pptx, .xlsx are opening as zip files. The configuration for SVN in apache is DAV svn SVNPath /repo/Test In which can we point the content to conf/mime.types file using TypesConfig conf/mime.types Or is there any methods like ModMimeUsePathInfo on Or AddType image/gif .gif or if any? Thanks & Regards, Dinoj D Desk: +91 80 26588360 Extn: 48547 Cell: +91 9916668051 -Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Tuesday, May 10, 2011 12:06 PM To: D, Dinoj Cc: users@subversion.apache.org Subject: Re: SVN files content Type On May 10, 2011, at 01:31, D, Dinoj wrote: > Can we make it possible to contact apache content type using any > modules..Setting the svn:mime-type to all individual files is not a good > solution If you want to serve the files directly out of the repository, then you must set the svn:mime-type property on each individual file. You can use auto-props in your config file on each client to make it easy to automatically add properties when adding files. There is a script you can run to retroactively apply those properties to your existing files in the repository too. And you can write a pre-commit hook script to prevent future files from being added without their required properties. But, consider not serving the files directly out of the repository. Instead, consider having a working copy of the appropriate subsection of the repository checked out on your web server and automatically updated at every commit. This will then use your normal Apache settings for mime type etc., and will additionally let you use server-side scripting languages like PHP if you want to. http://subversion.apache.org/faq.html#website-auto-update
RE: SVN files content Type
Ok, any plan of enhance this feature? Thanks & Regards, Dinoj D Desk: +91 80 26588360 Extn: 48547 Cell: +91 9916668051 -Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Tuesday, May 10, 2011 1:11 PM To: D, Dinoj Cc: users@subversion.apache.org Subject: Re: SVN files content Type On May 10, 2011, at 02:24, D, Dinoj wrote: > Thanks for your prompt response. The content type should be worked only > while accessing the files through web browser.The problem here we are > facing is that while accessing the files through web browser the > extensions .docx, .pptx, .xlsx are opening as zip files. The > configuration for SVN in apache is > > > DAV svn > SVNPath /repo/Test > > > > > In which can we point the content to conf/mime.types file using > > TypesConfig conf/mime.types > > Or is there any methods like > > ModMimeUsePathInfo on > > Or > AddType image/gif .gif or if any? No. Set the svn:mime-type property to the correct value on these files.
RE: SVN files content Type
Hi Daniel/Ryan Thanks. I understood that the mime content-types are not sending to the client from the server's mime.types file , intead it takes from the files which have subversion mime-type property set. I am unable to configure this to bypass to apache mime.types file. Here my requirement is that whoever accessing the repository through web browser must get the mime content-type from the apache file conf/mime.types and not from the svn:property. Please help on this. Thanks & Regards, Dinoj D Desk: +91 80 26588360 Extn: 48547 Cell: +91 9916668051 -Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: Tuesday, May 10, 2011 3:17 PM To: Ryan Schmidt Cc: D, Dinoj; users@subversion.apache.org Subject: Re: SVN files content Type Ryan Schmidt wrote on Tue, May 10, 2011 at 02:41:25 -0500: > > On May 10, 2011, at 02:24, D, Dinoj wrote: > > > Thanks for your prompt response. The content type should be worked only > > while accessing the files through web browser.The problem here we are > > facing is that while accessing the files through web browser the > > extensions .docx, .pptx, .xlsx are opening as zip files. The > > configuration for SVN in apache is > > > > > > DAV svn > > SVNPath /repo/Test > > > > > > > > > > In which can we point the content to conf/mime.types file using > > > > TypesConfig conf/mime.types > > > > Or is there any methods like > > > > ModMimeUsePathInfo on > > > > Or > > AddType image/gif .gif or if any? > > No. Set the svn:mime-type property to the correct value on these files. > If nothing else, it ought to be technically possible to throw an HTTP proxy that detects file extensions on GET requests to the mod_dav_svn -controlled location and rewrites the Content-Type for those. So, I'd expect there to be a way to configure httpd to bypass mod_dav_svn's reported MIME types. > >
RE: SVN files content Type
Hi, I have got some information that we can overwrite the header information if required. How can we set this for SVN? Thanks & Regards, Dinoj D Desk: +91 80 26588360 Extn: 48547 Cell: +91 9916668051 -Original Message- From: Ryan Schmidt [mailto:subversion-20...@ryandesign.com] Sent: Monday, May 16, 2011 12:14 PM To: D, Dinoj Cc: Daniel Shahaf; users@subversion.apache.org Subject: Re: SVN files content Type On May 16, 2011, at 00:42, D, Dinoj wrote: > Hi Daniel/Ryan > > Thanks. I understood that the mime content-types are not sending to the > client from the server's mime.types file , intead it takes from the > files which have subversion mime-type property set. I am unable to > configure this to bypass to apache mime.types file. That's correct. > Here my requirement > is that whoever accessing the repository through web browser must get > the mime content-type from the apache file conf/mime.types and not from > the svn:property. Please help on this. There's no way to configure Subversion to do that. As I already suggested, consider having a server-side post-commit hook that updates a server-side working copy of a relevant part of your repository, and point your apache at that working copy. Then, when users want to access this site, instruct users to use that other URL, not the repository URL. As a concrete example: Consider you have an HTML page in a project in a repository accessible here: http://www.example.com/svn/project1/trunk/folder/index.html You haven't been using svn:mime-type, so users who view this URL in a web browser will see the source of the document, instead of the page rendered as HTML which is what you want. Imagine your repository is on the server at /var/svn, and that you have a document root at /var/www used for everything at http://www.example.com/ other than the /svn directory, like this: ServerName www.example.com DocumentRoot /var/www DAV svn SVNPath /var/svn http://www.example.com/svn/project1/trunk project1 Now you can access that same HTML file from above at: http://www.example.com/test/project1/folder/index.html And now it will use the MIME types from the Apache configuration. Now, you install a post-commit hook script in the repository which basically does: svn up /var/www/test/* This way, every time anyone commits anything to the repository, the test directories will be updated as well. Updating "*" will be slow, so you can optimize this further if you like to just update the thing that was just committed.
ISO/FDA certified?
I am planning to use Subversion to control documents used in the development of medical instrumentation. Does anyone know if Subversion has been approved or certified by ISO or FDA for this us? Thanks, Dave Ramsey
Setting content type
Hello, If we are accessing subversion repository through WebDev module , then the content type will be send to the client depend the property what we have set for files. It won't look into apche mime types. But there is a way to edit the header information for Content-type For example: SetEnvIf Request_URI "\.docx$" docx_file RequestHeader edit Content-Type "application/vnd.openxmlformats-officedocument.wordprocessingml.document " env=docx_file But it is not working, could you please help me to configure this with svn ? Thanks & Regards, Dinoj D
Help! Subversion Exception!
This excepted when i tried to upgrade dir to 1.7 version of svn --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list (users@subversion.apache.org) with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\entries.c' line 1935: assertion failed (svn_checksum_match(entry_md5_checksum, found_md5_checksum)) --- ОК --- help me. Igor
Re: Help! Subversion Exception!
But if i have a lot of different local modifications in sources, you propose me to checkout??? You are crazy?
Checkout slow without proxy
Hello, we are using heavily "svn:externals" on our repositories. A full checkout of a typical repository takes 20 Minutes. If I configure a HTTP-Proxy in my subversion-client it takes only 13 Minutes... We are accessing our repository over an apache via https - due to the https-Connection no cache-hits should occour. How is it possible that a connection over a additional station is faster than a direct connection? I see also connections in "FIN_WAIT2"-State on the Server - can they slow down the checkout of the next external? We are using Subversion 1.5.1 on Apache 2.2 on the server-side (the Subversion-Server is not public availabe). I've tested with a Subversion-Client 1.7.1. Thanks in advance. Rgds. Dieter -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: Checkout slow without proxy
I think the reason is somewhere at the connection-specific configuration of apache in interaction with the behaviour of the subversion-client (which may has also connection-options...?). I suspect the KeepAlive-Handing... it seems that the subversion-client closes its connection between checking the different "externals" (which are on the same server) and the server keeps the connection opened and waits for further data. Until the connection is finally closed by timeout the server does NOT handle the request regarding the next "external". I don't have a clue why the server simply isn't accepting a second connection for the same client while the first connection is waiting for its timeout... I think one of the following options can affect this behaviour, but I'm still searching for an option which sounds like "ConnectionsPerClient": MaxRequestsPerChild KeepAliveTimeout Note: We are using a https-Connection. Original-Nachricht > Datum: Wed, 25 Jan 2012 14:35:33 -0600 > Von: Ryan Schmidt > An: d.guthm...@gmx.net > CC: users@subversion.apache.org > Betreff: Re: Checkout slow without proxy > > On Jan 25, 2012, at 03:43, d.guthm...@gmx.net wrote: > > > We are using Subversion 1.5.1 on Apache 2.2 on the server-side > > As a first step, you should upgrade the Subversion software on your > server. Subversion 1.5.x and earlier are not supported anymore. > > http://subversion.apache.org/docs/release-notes/1.7.html#svn-1.5-deprecation > > -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
[no subject]
Hello, we run a subversion-server with apache and access it through https. Now we want to grant also external developers access to our repositories. As subversion-client we use subclipse via JavaHL under Windows. The https-Port on the server is not reachable from any external network. I've now found the subversion-feature "svn+ssh" and I would like to use it as a tunnel from those external developers computer. So the URL would be "svn+ssh://user@hostname:220/srv/svn/project/" - normally we use the URL "https://hostname/repos/projekt/"; Would it work properly (e.g. executing hooks) or is it a problem to access one repository in two different ways? The URL "svn+ssh://user@hostname:220/srv/svn/projekt/" suggests that we are bypassing the svn-Module... We also use some access-control features like "AuthzSVNAccessFile" in the Apache-configuration - am I right assuming that those access-control doesn't take effect when accessing over svn+ssh://? Thanks in Advance. Rgds. Dieter -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: svn+ssh vs. https (different access methods)
Hello, first of all: I'm really sorry for the missing subject-line. original message > Will it stay with access on the repositories only or is it will your > external devs need access to test infrastructure, documentation or > whatever, too? In the latter case I would prefer setting up a proper > VPN infrastructure which allows you to use Apache as the svn host for > your external devs and only let them see specific networks they need > via routing, firewall etc. Normally I would agree to you, but it would be too extensive to gave only to that part of our network, which is necessary for that project, when using a VPN-Client. So the VPN-Connection would be restricted only to the Subversion-Service, so I seems to be easier to set up a SSH-Tunnel than a VPN-Service. A better solution would be a kind of proxy-service that I can place in the DMZ... is there a working proxy-solution for subversion? Some time ago I've gave access to a subversion-repository via a reverse-proxy running on apache... that wasn't working properly... Are there other proxy-like services which will work well with subversion? Thanks. Rgds. Dieter -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: svn+ssh vs. https (different access methods)
Hello, Original-Nachricht > What kind of trouble did you have with apache in the reverse-proxy > mode? I've had that working and I think the only issue was that the > relative path had to be the same as the actual target. That is you > can't proxy http:/realhost/svn as http://proxyhost/somewhere/svn. > Also for a straight passthrough you might run stunnel accepting https > from outside your dmz, connecting to http on the inside server. I had a problem using the COPY-Command over the connections established over the reverse-proxy... "Server sent unexpected return value (502 Bad Gateway) in response to COPY request for ..." But today I've found out that there is a solution using Apache 2.2.4 or greater (add "RequestHeader edit Destination ^https http early" to the Subversion-Configuration): http://www.thedumbterminal.co.uk/php/knowledgebase/article/141 Rgds Dieter -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Connection Time out error
HiAm getting the following error, when i try to check out a big directoryREPORT of '/svn/code/!svn/vcc/default': Could not read response body: An existing connection was forcibly closed by the remote host.I have seen lot of people come across this issue on the internet but haven't come across any solution so far. Any insight or workaround for this issue is greatly appreciated ThanksJohn _ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010
Protected/secure SVN
Hi, I would like to set up SVN to store confidential documents. I have secured the pipe communication with HTTPS/SSL. To avoid unauthorized users (even with root access) accessing documents from within the server, I would like to protect the SVN linux folder/files with encryption. Are there any ways to secure the SVN using protected folders or encryption? So only authorized users can access these confidential documents. Thanks in advance for your helps.
SVN not updating original file
Hi SVN mailing list! I'm a first timer with SVN and am having problems. I followed this simple howto: http://www.tonyspencer.com/2007/03/02/setup-a-subversion-server-in-4-minutes/ Now I have a repo setup that is accessible from remote clients. I can checkout the repo files, edit any of the files included and commit these changes back to SVN. To double-check I checked out the repo on a separate machine and was able to see my changes made from the first workstation. The problem I have is that the original file never changes, no matter how many changes I make. For example here's how my layout looks: /svn/scripts<-- This folder has my original script files I want SVN to track and update "svn import /svn/scripts file:///svn/scripts" is the command I run to create the repo /svn/scripts/check.sh <-- this is the file I change on my remote client So after I change this file, I commit the changes back to SVN and this appears to work, however the file /svn/scripts/check.sh remains the same, original un-edited file. What am I doing wrong? Seems simple enough it just doesn't work. Thanks!
Re: SVN not updating original file
I've read lots of tutorials on setting up and importing projects into SVN and the majority of them use file:/// so maybe it's just a matter of choice on how to import your project. As for my issue, the solution is this: Delete the contents of /svn/scripts and then checkout a working copy from SVN into the folder /svn/scripts whala!! Now I have my files under version control and I can commit changes directly! Thanks for your input!! |> | From: | |> >--| |Andy Levy | >--| |> | To:| |> >--| |Christopher D Haakinson/Raleigh/IBM@IBMUS | >--| |> | Cc:| |> >--| |users@subversion.apache.org | >--| |> | Date: | |> >--| |02/22/2011 11:14 AM | >--| |> | Subject: | |> >--| |Re: SVN not updating original file | >------| On Tue, Feb 22, 2011 at 10:58, Christopher D Haakinson wrote: > Hi SVN mailing list! I'm a first timer with SVN and am having problems. > > I followed this simple howto: > > http://www.tonyspencer.com/2007/03/02/setup-a-subversion-server-in-4-minutes/ > > Now I have a repo setup that is accessible from remote clients. I can > checkout the repo files, edit any of the files included and commit these > changes back to SVN. To double-check I checked out the repo on a separate > machine and was able to see my changes made from the first workstation. > > The problem I have is that the original file never changes, no matter how > many changes I make. > > For example here's how my layout looks: > > /svn/scripts <-- This folder has my original script files I want SVN to > track and update > > "svn import /svn/scripts file:///svn/scripts" is the command I run to create > the repo > > /svn/scripts/check.sh <-- this is the file I change on my remote client > > So after I change this file, I commit the changes back to SVN and this > appears to work, however the file /svn/scripts/check.sh remains the same, > original un-edited file. > > What am I doing wrong? Seems simple enough it just doesn't work. Thanks! What that tutorial fails to point out is that when you use svn import, there is no connection made between the local directory and the repository. All it does is push the contents of the local directory into the repository. This confusion can be mitigated by performing an "in-place import" instead of a vanilla import. See http://subversion.apache.org/faq.html#in-place-import However, since you've already done the import, the safest route to go now is to just check out a working copy from the repository. Please also read the fine manual, http://svnbook.org/ . A "simple, 4-minute how-to" might *seem* OK for gettin
^M Appends to every line?
I have SVN up and running and things are working well, except when editing shell scripts from windows. My server is RHEL5-based and I will have clients connecting from linux and windows. Linux commits work great, and even some times from windows. However some times I commit a file from Windows(running tortoiseSVN and Komodo EDIT) it corrupts the script and adds ^M to the end of every line, often times ruining the structure of the file too. Is there a way to disable this or do I have to run a dos2unix script after every commit to remove them?
Re: ^M Appends to every line?
OK, so I've been testing out the svn:eol-style prop and it appears to work, but it seems like an awful lot of work for such a simple issue. Is there something server-side I can setup to ensure that all files contain the correct eol style? Also I've noticed that my shell scripts are now failing with an EOF error? Does this mean that there's a style setting for the end of file too?? |> | From: | |> >| |Ryan Schmidt | >| |> | To:| |> >| |David Chapman | >| |> | Cc:| |> >| |Nico Kadel-Garcia , users@subversion.apache.org | >| |> | Date: | |> >| |02/23/2011 09:04 PM | >| |> | Subject: | |> >| |Re: ^M Appends to every line? | >| On Feb 23, 2011, at 19:48, David Chapman wrote: > On 2/23/2011 4:44 PM, Nico Kadel-Garcia wrote: >> On Wed, Feb 23, 2011 at 11:39 AM, Les Mikesell wrote: >>> Short version: set the svn:eol-style property to native on the files where >>> you want subversion to manage line endings. Your client may have a list of >>> file suffixes where this would be set automatically. >> But in general, avoid it. If you're in a mixed platform environment, >> and you are tweaking files back and forth in end-of-line settings when >> you check them out in UNIX versis checking them out in Windows, you >> are in for a *world* of hurt. This is a source of enormous confusion >> for programmers when it works right, on one system, but not on the >> other due to local re-writing. >> >> If you're on the UNIX or Linux sides, the "dos2unix" and "unix2dos" >> utilities are available with almost every distribution. For Windows, >> there are other tools, including the same tools under CygWin. > > Uh, no. Use of "svn:eol-style" avoids a world of hurt - programmers do not have to run a script *every* time they check out a file. Requiring users to run a script to fix line endings in every sandbox is a recipe for disaster. > > "dos2unix" and "unix2dos" are precisely the kind of local rewriting you want to avoid. Some have the view that setting svn:eol-style to native is a problem; perhaps that's what Nico meant. Certainly, it would be a problem (wouldn't work as designed) if you check out a working copy on a platform with one eol convention (e.g. Mac OS X) and move that working copy to an OS with a different eol convention (e.g. Windows). If that is something you plan to do, the alternative is to still use svn:eol-style but set it to a specific eol style instead -- for example LF. Then you would have to configure all your editors on all platforms to use that line ending style.* * Actually it does not matter if the editor decided, for example, to completely convert the file from, say, LF to CRLF line endings. On commit, your Subversion client would notice the change and convert it back to just LF before submitting it to the repository. The situation Subversion won't handle for you, and will a
Re: ^M Appends to every line?
Linux is the final home for these scripts. Currently I'm still in testing mode, so the shell script I am trying is very simple, only a few lines with a while loop, which is why I thought there may be something like svn:eof-style to handle the EOF properly too.. |> | From: | |> >| |David Chapman | >| |> | To:| |> >----| |Christopher D Haakinson/Raleigh/IBM@IBMUS | >| |> | Cc:| |> >| |Ryan Schmidt , users@subversion.apache.org | >| |> | Date: | |> >| |02/24/2011 11:22 AM | >| |> | Subject: | |> >| |Re: ^M Appends to every line? | >----| On 2/24/2011 8:02 AM, Christopher D Haakinson wrote: > > OK, so I've been testing out the svn:eol-style prop and it appears to > work, but it seems like an awful lot of work for such a simple issue. > > Is there something server-side I can setup to ensure that all files > contain the correct eol style? > > > Also I've noticed that my shell scripts are now failing with an EOF > error? Does this mean that there's a style setting for the end of file > too?? > > > You can define a pre-commit hook script that looks at the file name and then verifies the property is present. These are described in the Subversion book. Multi-platform work is an awful lot of work; it is not as simple as it seems. Heuristics to determine whether a file is "plain text" can fail, with catastrophic results. File transfers done carelessly will corrupt binary files; in integrated circuit design the OASIS geometry file format has an "almost text" string defined solely to catch this error. If you try to use the same text files across platforms, things will fail unless *every* tool you use - all editors, all file analysis software, all file transfer programs - deals with mixed or "wrong platform" line ending styles properly. This is a high standard that has never been met in my experience. I haven't seen script errors related to end of file; Windows no longer puts a ^Z at the end of files, so you shouldn't need to strip that out. Have you done an octal dump of the scripts to see what is at the end of the files? On which platform are they failing - Windows or Linux? -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA <><>
Re: ^M Appends to every line?
I'd like someone to explain how this small shell script, which works fine, gets corrupted simply by creating a new file and copy/pasting the text in it. Here's what I'm doing: 1) I have a test shell script that runs fine. Here's the content: <- start lock="/tmp/deleteme" if [ -f $lock ] then echo "Lock file exists. Wait until it's gone to proceed. ." while [ -f $lock ] do echo "Waiting for lockfile to be removed. ." sleep 1s done echo "Now creating lock file" echo "locked" > $lock else echo "No lock file found. Creating it. ." echo "locked" > $lock fi echo "Lets try this again, hopefully for the last time" exit 0 <-- end 2) I copy this entire script from notepad in windows into a new file named test2.sh, also in notepad. 3) Using TortoiseSVN, I add test2.sh into my project 4) I commit the changes to the server 5) On my linux server, I run: svn update ... to get the test2.sh file 6) Now when I try to run it I get this: syntax error: unexpected end of file Now, this is the most simple task I could think of doing, and this doesn't work. I've also tried creating the new shell script with Komodo EDIT with the same results. This occurs even though I've tried adding svn:eol-style from both my linux server and my windows wrx... I'm lost!! |> | From: | |> >| |Les Mikesell | >| |> | To:| |> >| |users@subversion.apache.org | >| |> | Date: | |> >| |02/24/2011 11:27 AM | >| |> | Subject: | |> >| |Re: ^M Appends to every line? | >----| On 2/24/2011 10:02 AM, Christopher D Haakinson wrote: > OK, so I've been testing out the svn:eol-style prop and it appears to > work, but it seems like an awful lot of work for such a simple issue. > > Is there something server-side I can setup to ensure that all files > contain the correct eol style? No, the server can't possibly know what is right either for any particular file or for any particular client platform. But, your client configs control auto-props which can sometimes do the right thing automatically on the client side. Unfortunately those have to match filename patterns that won't necessarily correspond to the file content or use. > Also I've noticed that my shell scripts are now failing with an EOF > error? Does this mean that there's a style setting for the end of file too?? No, that probably is related to some other error or parsing issue in the file. -- Les Mikesell lesmikes...@gmail.com <><>
Re: ^M Appends to every line?
It's possible that the eol-style has nothing to do with this, because before I added the style, my script was still failing and complaining about the EOF as well as EOL errors... Running your od command yields the following on the last 3 lines: 620 s t t i m e . . . . " \r \n \r \n 640 \r \n e x i t 0 650 so it is missing \n ... I opened the file in notepad and added a couple blank lines under my exit 0 and it worked!! How weird is that? Thanks for your help! It's been much appreciated. |> | From: | |> >-| |David Chapman | >-| |> | To:| |> >-----| |Christopher D Haakinson/Raleigh/IBM@IBMUS | >-| |> | Cc:| |> >-| |users@subversion.apache.org | >-| |> | Date: | |> >-| |02/24/2011 01:28 PM | >-| |> | Subject: | |> >-| |Re: ^M Appends to every line? | >-----| On 2/24/2011 9:55 AM, Christopher D Haakinson wrote: > > I'd like someone to explain how this small shell script, which works > fine, gets corrupted simply by creating a new file and copy/pasting > the text in it. Here's what I'm doing: > > 1) I have a test shell script that runs fine. Here's the content: > <- start > lock="/tmp/deleteme" > if [ -f $lock ] > then > echo "Lock file exists. Wait until it's gone to proceed. ." > while [ -f $lock ] > do > echo "Waiting for lockfile to be removed. ." > sleep 1s > done > echo "Now creating lock file" > echo "locked" > $lock > else > echo "No lock file found. Creating it. ." > echo "locked" > $lock > fi > echo "Lets try this again, hopefully for the last time" > exit 0 > <-- end > > 2) I copy this entire script from notepad in windows into a new file > named test2.sh, also in notepad. > 3) Using TortoiseSVN, I add test2.sh into my project > 4) I commit the changes to the server > 5) On my linux server, I run: svn update ... to get the test2.sh file > 6) Now when I try to run it I get this: > syntax error: unexpected end of file > > > Now, this is the most simple task I could think of doing, and this > doesn't work. I've also tried creating the new shell script with > Komodo EDIT with the same results. > > This occurs even though I've tried adding svn:eol-style from both my > linux server and my windows wrx... I'm lost!! > In Notepad, can you move your cursor below the last line of text in the file? If not, there won't be a newline after the final line. Under Linux, try "od -c test2.sh | more
svn update or rsync - which is best to update live files
Hi, I have subversion up and running quite well now(thanks to everyone here :-)) Now I've come to the point in my development where I need to figure out what's the best method for transferring my svn files to my live site. I've read that I should use a post-commit hook, which is fine I'm using a pre-commit hook already so I'm aware of how they work. My main question is: Which method is best for updating my live files? Should I use rsync in my post hook or should I use svn update? http://subversion.apache.org/faq.html#website-auto-update this page recommends using svn update, but I wanted to get some input from the community too. Thanks in advance!
Help with files changed outside of svn
I'm fairly new to svn, and I have things set up and running well. I wanted to test out a scenario where a file controlled by svn gets changed outside of svn inside the working copy, and now I'm lost and can't find much help on what to do. Here's my example: I setup the hooks folder as a svn project. Checked it out onto my windows box and made a small change, then committed the changes. Now I went through my command shell and manually changed a file outside of svn. Then I went back to my windows box and editted the same file with a different change. Now the original file contains: ">>> .r3" at the bottom Also I have some more files inside my working directory too: pre-revprop-change.tmpl pre-revprop-change.tmpl.mine pre-revprop-change.tmpl.r2 pre-revprop-change.tmpl.r3 Can someone please explain to me: 1) Why does >>> get put into the bottom of my files? 2) What are the 3 copies of this file for? 3) And now how do I get these files merged back into one copy with the changes made inside svn included and the changes made outside svn excluded?
Re: Help with files changed outside of svn
I mean that I have a working copy of my project under: /svn/hooks This folder gets automatically updated with svn update on every commit with a post-commit hook This folder also is "live", meaning that the files here are in use at all times, so nobody will be using this "working copy" as their development copy, it's just there to receive all the newest changes. The scenario I want to test and know how to handle is when a file in /svn/hooks gets changed outside of svn and these changes never get commited into svn. I understand what svn is and is not, but the files I will have inside svn will also be available and writable on a network, so I need to know how to handle files that get changed inside my live working folder outside of svn. Also is there a way to change what gets written to a file when this occurs? All my scripts get corrupted because of the >>>>>>> and I'd like to at least put a # in front so that it's a commented line and doesn't affect the execution... |> | From: | |> >-| |Andy Levy | >-| |> | To:| |> >-| |Christopher D Haakinson/Raleigh/IBM@IBMUS | >-| |> | Cc:| |> >-| |users@subversion.apache.org | >-| |> | Date: | |> >-| |02/28/2011 11:02 AM | >-| |> | Subject: | |> >-| |Re: Help with files changed outside of svn | >-----| On Mon, Feb 28, 2011 at 10:54, Christopher D Haakinson wrote: > I'm fairly new to svn, and I have things set up and running well. > > I wanted to test out a scenario where a file controlled by svn gets changed > outside of svn inside the working copy, and now I'm lost and can't find much > help on what to do. > > Here's my example: I setup the hooks folder as a svn project. Checked it out > onto my windows box and made a small change, then committed the changes. > Now I went through my command shell and manually changed a file outside of > svn. > Then I went back to my windows box and editted the same file with a > different change. Do you mean to say that you edited the same file in multiple working copes? There is no "outside" svn as svn isn't a program in which you edit files, and you can't edit directly in the repository. > Now the original file contains: ">>>>>>> .r3" at the bottom > > Also I have some more files inside my working directory too: > > pre-revprop-change.tmpl > pre-revprop-change.tmpl.mine > pre-revprop-change.tmpl.r2 > pre-revprop-change.tmpl.r3 > > > Can someone please explain to me: > > 1) Why does >>>>>>> get put into the bottom of my files? > 2) What are the 3 copies of this file for? You have
How to migrate just part of a repo to another server
I'm trying to move just a few directory trees from a subversion repo to another server. On the old server, I run svndump /path/to/old/repo > /tmp/svn-dumpfile I've copied the svn-dumpfile to the new server. Now, when I try to run cat svn-dumpfile | svndumpfilter include /htdocs/CCDB | svnadmin load /path/to/new/repo I get an error from svndumpfilter: svndumpfilter: Invalid copy source path '/CCDB' and I don't see anything in my new repo. What am I doing wrong? -- Todd D. Taft UNC Computational Systems Biology todd_t...@unc.edu
VSS to SVN Migration.
Hi, I'm new to SVN. Actually we were using VSS for source control. Now we are going to migrate from VSS to SVN. So like to know the possible options for it. Regards, Sandeep.U.D
malformed file problem -- version 1.5.7
Hello, One of my users committed a file to svn and now some users are getting a 'malformed file' error. These users can no longer check out or commit. 'Svnadmin verify /svnrepos' doesn't show any problems, however 'malformed file' appears when I do a nightly dump export; svnadmin dump /svnrepos > /backup/svnrepos.svn_dump * Dumped revision 11529. svnadmin: Malformed file I believe the problem lies within revision numbers 11530 and 11532. Other users who are working on other projects are not having problems. We are currently at revision 11784. Is there a way that I can repair this? Many thanks in advance, James
RE: malformed file problem -- version 1.5.7
One of my users committed a file to svn and now some users are getting a 'malformed file' error. These users can no longer check out or commit. 'Svnadmin verify /svnrepos' doesn't show any problems, however 'malformed file' appears when I do a nightly dump export; svnadmin dump /svnrepos > /backup/svnrepos.svn_dump * Dumped revision 11529. svnadmin: Malformed file I believe the problem lies within revision numbers 11530 and 11532. Other users who are working on other projects are not having problems. We are currently at revision 11784. Is there a way that I can repair this? ~~~ Is there a way to roll back to revision 11529 and start there? Should I remove all the revision number files greater that 11529 and have my users check out again? Trying to figure out the best way to fix this. Many thanks, James
RE: malformed file problem -- version 1.5.7
> Is there a way that I can repair this? No idea, sorry. But: > Is there a way to roll back to revision 11529 and start there? Try svnadmin dump with the -r parameter to dump just the revisions you want to keep, then svnadmin load to load them into a new repository. Any checkouts of r11529 or earlier should be OK; if you have a later checkout then you'll need to delete it and re-checkout. > Should I remove all the revision number files greater that 11529 Hand-editing the repository sounds like a bad idea*... you might get rid of this corruption but introduce a different corruption. Using dump/load should give you a valid repository. Kind regards, Jon [*] It's number zero on the "Subversion Worst Practices" guide: http://www.red-bean.com/fitz/presentations/2007-07-27-OSCON-svn-worst-pr actices.pdf ~~ Thank you, Jon, for the info. Before I do such a major rollback, is there a way to rollback a particular project within the repos without affecting other projects or, to be more concise, maintain revision numbers for the other projects that are not affected by the mal-formed file error? Thanks again for your help. James
a bug / mis-feature in ra_serf
Hello, I found an issue with the ra_serf SVN module. The problem is that during the commit via ra_serf it tries to keep all files open (or something like this), so if there is a limit on number of open files and it's lower that the number of files to commit, then SVN client fails with: === svn: Commit failed (details follow): svn: Can't find a temporary directory: Internal error === To reproduce the issue one need to create an empty repository, check it out via HTTP/HTTPS, then populate with, say, 2000 files. At this point, set the number of open files limit to 1024 (ulimit -n 1024). After this if you try to commit them back it will work perfectly with ra_neon, but will fail if you are using ra_serf. I've verified this with the latest version of Subversion (1.6.9), the latest version of neon (0.29.3), and serf 0.30 (I had no time to build and verify version 0.31, sorry). Hope this helps. -- Dmitry D. Khlebnikov Openwall [http://openwall.com]
a bug / mis-feature in ra_serf
Hello, I found an issue with the ra_serf SVN module. The problem is that during the commit via ra_serf it tries to keep all files open (or something like this), so if there is a limit on number of open files and it's lower that the number of files to commit, then SVN client fails with: === svn: Commit failed (details follow): svn: Can't find a temporary directory: Internal error === To reproduce the issue one need to create an empty repository, check it out via HTTP/HTTPS, then populate with, say, 2000 files. At this point, set the number of open files limit to 1024 (ulimit -n 1024). After this if you try to commit them back it will work perfectly with ra_neon, but will fail if you are using ra_serf. I believe it could be reproduced with smaller numbers, say, 200 files and a limit of 150, but I haven't tested it. I've verified this with the latest version of Subversion (1.6.9), the latest version of neon (0.29.3), and serf 0.30 (I had no time to build and verify version 0.31, sorry). Hope this helps. -- Dmitry D. Khlebnikov Openwall [http://openwall.com]
Subversion Exception will attempting to modify ignore list
I use TortoiseSVN to access Subversion. I'm reporting this here because the popup said to do so. I attempted to add some files to the ignore list. When I tried to commit the changes, Subversion said I had a tree conflict, but nothing I could do allowed me to resolve the conflict. So I attempted to revert the ignores and got the following popup. What other information and how to find it do you need? David D. Miller NCR SelfServ(tm) Checkout Software Architect NCR Corporation phone:770.623.7233 david.d.mil...@ncr.com<mailto:david.d.mil...@ncr.com> | www.ncr.com<http://www.ncr.com> <>
Files ending with . (dot) on Windows
We recently added files from a 3rd party tool to our repository and some of the file names end with . (dot). On UNIX systems, this is perfectly fine and everyone is happy, but on Windows systems the files are reported as missing and a corresponding file without the . at the end of the file name is listed as not being under version control (with SVN 1.6.17 client) or the repository just can't be checked out (with SVN 1.8.0 client). This doesn't appear to be a bug in Subversion, as Windows doesn't allow files to end with a dot and doesn't seem to handle them gracefully when they do. From http://msdn.microsoft.com/en-us/library/aa365247.aspx: "Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not. However, it is acceptable to specify a period as the first character of a name. For example, ".temp"." Here's a simple walkthrough that demonstrates the behavior: On a UNIX system add a file with a name ending in . to the repository: -bash-3.00$ touch src/main/resources/fileEndingWithDot. -bash-3.00$ svn status ? src/main/resources/fileEndingWithDot. -bash-3.00$ svn add src/main/resources/fileEndingWithDot. A src/main/resources/fileEndingWithDot. -bash-3.00$ svn commit . -m "Adding a file with name ending in dot to demonstrate behavior on Windows" Adding src/main/resources/fileEndingWithDot. Transmitting file data Committed revision 22. -bash-3.00$ svn status -bash-3.00$ As you can see, everything works as expected. When using an older svn client on Windows (svn, version 1.6.17 (r1128011) compiled Jun 2 2011, 23:35:08, Copyright (C) 2000-2009 CollabNet) it's possible to check out the repository: C:\tmp\playrepo>svn co /trunk Atrunk\.classpath Atrunk\.project Atrunk\src Atrunk\src\test Atrunk\src\test\java Atrunk\src\test\resources Atrunk\src\main Atrunk\src\main\java Atrunk\src\main\java\com Atrunk\src\main\java\com\saic Atrunk\src\main\java\com\saic\isd Atrunk\src\main\java\com\saic\isd\TestInterface.java Atrunk\src\main\java\com\saic\isd\HelloWorld.java Atrunk\src\main\resources Atrunk\src\main\resources\fileEndingWithDot. Atrunk\pom.xml U trunk Checked out revision 22. But users constantly get a misleading status on the files with problem file names. C:\tmp\playrepo\trunk>svn status ? src\main\resources\fileEndingWithDot ! src\main\resources\fileEndingWithDot. C:\tmp\playrepo\trunk> In a recent svn client on Windows (svn, version 1.8.0 (r1490375) compiled Jun 17 2013, 08:08:13 on x86-microsoft-windows, Copyright (C) 2013 The Apache Software Foundation) attempting to check out the repository fails: C:\tmp\playrepo>svn co /trunk Atrunk\.classpath Atrunk\.project Atrunk\src Atrunk\src\test Atrunk\src\test\java Atrunk\src\test\resources Atrunk\src\main Atrunk\src\main\java Atrunk\src\main\java\com Atrunk\src\main\java\com\saic Atrunk\src\main\java\com\saic\isd Atrunk\src\main\java\com\saic\isd\TestInterface.java Atrunk\src\main\java\com\saic\isd\HelloWorld.java Atrunk\src\main\resources svn: E155000: 'fileEndingWithDot.' is not valid as filename in directory 'C:\tmp\playrepo\trunk\src\main\resources' Is there a known work around for this? Was there a conscious decision between 1.6 and 1.8 to change this behavior, or have I stumbled across a bug? Our Windows users can continue to use the older svn client so that working with the repo is still possible, but they'd like to stop seeing the missing/not controlled status messages. Normally, I'd just rename the files to something that both platforms can handle, but since these files are delivered from a 3rd party I'd like to avoid that if at all possible. I'm not subscribed to this list and would appreciate being explicitly cc'ed in any responses. Thanks in advance for any help or advice! --Brad Staton stat...@saic.com
make install fails to install mod_authz_svn.so/mod_dav_svn.so
While upgrading from 1.6 to 1.8, I noticed that make install failed to copy mod_authz_svn.so/mod_dav_svn.so to /path/to/apache/modules per the INSTALL which resulted in these errors on seemingly random commits: Delta source ended unexpectedly [500, #23] could not write the file contents [500, #23] I don't see a rule in the Makefile to apxs -i or otherwise copy those DSOs though they are correctly built and configure correctly sets INSTALL_APACHE_MODS = true in the Makefile I'm on Solaris 10 and my configure is so: $ env PATH=/opt/subversion/apache2/bin:/usr/bin:/usr/sbin:/usr/ccs/bin:/opt/solarisstudio12.3/bin:/usr/sfw/bin \ CC=cc CFLAGS="-m64 -xO3" \ LDFLAGS="-m64 -L/usr/sfw/lib/64 -R/usr/sfw/lib/64" \ CPPFLAGS=-I/usr/sfw/include \ ./configure --prefix=/opt/subversion \ --with-sqlite=/opt/subversion/sqlite \ --with-serf=/opt/subversion/serf --with-openssl \ --without-gnome-keyring --with-apxs=/opt/subversion/apache2/bin/apxs Not sure if I need to be swatted with a clue stick of if I've stumbled over a bug. The hack was to copy the DSOs manually. John groenv...@acm.org
Re: make install fails to install mod_authz_svn.so/mod_dav_svn.so
In message <87ioz5iypv@ntlworld.com>, Philip Martin writes: >install-mods-shared: subversion/mod_dav_svn/mod_dav_svn.la subversion/mod_auth >z_svn/mod_authz_svn.la >if $(INSTALL_APACHE_MODS) ; then cd subversion/mod_dav_svn ; $(MKDIR) >"$(APACHE_LIBEXECDIR)" ; $(INSTALL_MOD_SHARED) -n dav_svn mod_dav_svn.la ; fi $ make -n install if true ; then cd subversion/mod_dav_svn ; /tmp/subversion-1.8.1/build/install-sh -c -d "/opt/subversion/libexec" ; /opt/subversion/apache2/bin/apxs -i -S LIBEXECDIR="/opt/subversion/libexec" -n dav_svn mod_dav_svn.la ; fi This doesn't match INSTALL which suggests they should go to /path/to/httpd/modules: After the make install, the Subversion shared libraries are in /usr/local/lib/. mod_dav_svn.so should be installed in /usr/local/apache2/modules/. John groenv...@acm.org
Receiving an error via an SVN repository
Hello, We are running Tortoise SVN on a Windows 7 machine - and had some network issues were connectivity to our share where the repository was stored was up and down. We've had the user copy the files locally and they can access them and commit them but when trying to recommit them to the network repository they were getting a file lock error. The user was able to break the lock but now receives this error : Error: Can't set position pointer [...] : An attempt was made to move the file pointer before the beginning of the file and can't reconnect to the SVN repository on the network. I see this link to http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html to unwedge a repository but wanted to check to see if you had any recommendations on what to do before trying to do a restore of the repository or should we try the "unwedge" action first? Thanks much in advance for your assistance. Ronda Sinclair
Commit Exception
While I was dragging into Tortoise commit dialog, I encountered the following messages box dozens of times. --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.9.4\ext\subversion\subversion\lib svn_wc\wc_db.c' line 10925: assertion failed (svn_dirent_is_absolute(local_abspath)) --- OK --- Then, it seemed to work fine, so he proceeded with the commit, only to get the following message: Error: In file Error: 'D:\Development\SVN\Releases\TortoiseSVN-1.9.4\ext\subversion\subversion\lib svn_client\commit.c' Error: line 491: assertion failed (rel_target != NULL && *rel_target != '\0') It seemed to be caused by committing changes from multiple drives at the same time. My solution was simply to move the folders all to one drive, then it worked fine. Matt Hansen ISA Corporation ACC/84RADES USAF 801-777-6264 smime.p7s Description: S/MIME cryptographic signature
