Re: Cannot checkout or clean up using 1.9 dev build
On Apr 28, 2015 8:02 AM, Ivan Zhakov i...@visualsvn.com wrote: I've fixed at least one problem in svn_stream__install*() on Windows with long path names in r1676526. But I was getting different error message on Windows 8.1. Benjamin, what operating system do you use? Windows 7
svn diff produces invalid XML if path contains bell character
Hi there, it seems that svn diff produces invalid XML if a path contains a bell characters. Since this character is not allowed in XML it should be escaped. It seems that svn diff does not to this. Is there an existing bug for this problem? Regards, Brian Preuß
Re: Cannot checkout or clean up using 1.9 dev build
On 28 April 2015 at 16:15, Benjamin Fritz fritzophre...@gmail.com wrote: On Apr 28, 2015 8:02 AM, Ivan Zhakov i...@visualsvn.com wrote: I've fixed at least one problem in svn_stream__install*() on Windows with long path names in r1676526. But I was getting different error message on Windows 8.1. Benjamin, what operating system do you use? Windows 7 Thanks! I've tested and I'm getting the same error as you reported on Windows 7, so problem is very likely fixed in r1676526. I'm going to nominate it to 1.9.x then. -- Ivan Zhakov
Re: Cannot checkout or clean up using 1.9 dev build
On 28 April 2015 at 10:07, Ivan Zhakov i...@visualsvn.com wrote: On 27 April 2015 at 21:35, Benjamin Fritz fritzophre...@gmail.com wrote: Apparently I'm not subscribed to get list emails; please CC me on future responses. I had to get this message from the archive :-) Branko Čibej wrote: On 27.04.2015 18:06, Benjamin Fritz wrote: I get the following error when I try to check out a working copy from my repository at work (exact path names obfuscated but length unchanged, in case it matters It probably does matter ... FWIW, I believe you did change the length of the file name, the workqueue record says 234 chars but the name in the record is 240; still, that shouldn't be an issue. Oops. You're right. My actual directory has only 3 characters where I replaced with Prog in the path string. Still, those 6 fewer characters are probably irrelevant. ), leaving a partially downloaded working copy: svn: E155009: Failed to run the WC DB work queue associated with 'C:\Project_Files\Proj_Dev\Prog_svn_1.9_cmdline', work item 2160 (file-install 234 Logical_Architecture/APP/App_PL_Verification/XXX/XXX_XXXs/XXX_7_APPDB_PROJ_PROG--0021_BE/APPDB_PROJ_PROG--0021.SUP/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021.SUP/XXX_APPDB_PROJ_PROG--002101.CRC 1 0 1 1) svn: E720123: The filename, directory name, or volume label syntax is incorrect. The full path of the file would be 281 characters long, which is more than Windows' limit of 260. But Subversion goes to a lot of trouble to avoid the path limit ... I wonder what's going on here. It seems Windows specific implementation of svn_stream__install_stream() doesn't prepend path with \\?\ for long names. Replacing svn_utf__win32_utf8_to_utf16() call with svn_io__utf8_to_unicode_longpath() should fix the problem, but I didn't try yet. I've fixed at least one problem in svn_stream__install*() on Windows with long path names in r1676526. But I was getting different error message on Windows 8.1. Benjamin, what operating system do you use? -- Ivan Zhakov
Re: Dealing with very old repo format (version 1)
On Tue, Apr 28, 2015 at 5:03 PM, Andrew Reedick jreed...@incomm.com wrote: Does anyone have any tips on how to upgrade a very old repo? The db/format lists 1. A 1.8 svn client cannot hotcopy, dump or svnadmin upgrade such an old repo, all of which fail with svnadmin: E720002: Can't open file 'devel\db\current': The system cannot find the file specified. Do I need find a really old svn client (1.3?) and upgrade? Do I need to manually create the db/current file? Supposedly , a format of 1 is from pre-svn 1.0. https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h - Formats 0, 1 and 2 were pre-1.0. Why can't you do a fresh working copy, and copy all files except those in '.svn' subdirectories?
Re: Dealing with very old repo format (version 1)
On 29.04.2015 05:09, Nico Kadel-Garcia wrote: On Tue, Apr 28, 2015 at 5:03 PM, Andrew Reedick jreed...@incomm.com wrote: Does anyone have any tips on how to upgrade a very old repo? The db/format lists 1. A 1.8 svn client cannot hotcopy, dump or svnadmin upgrade such an old repo, all of which fail with svnadmin: E720002: Can't open file 'devel\db\current': The system cannot find the file specified. Do I need find a really old svn client (1.3?) and upgrade? Do I need to manually create the db/current file? Supposedly , a format of 1 is from pre-svn 1.0. https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h - Formats 0, 1 and 2 were pre-1.0. Why can't you do a fresh working copy, and copy all files except those in '.svn' subdirectories? Without db/current, he can't perform a checkout, and if he could and just copied the file, he'd be throwing away all history. -- Brane
Re: Dealing with very old repo format (version 1)
On 28.04.2015 23:03, Andrew Reedick wrote: Does anyone have any tips on how to upgrade a very old repo? The db/format lists 1. A 1.8 svn client cannot hotcopy, dump or svnadmin upgrade such an old repo, all of which fail with svnadmin: E720002: Can't open file 'devel\db\current': The system cannot find the file specified. Do I need find a really old svn client (1.3?) and upgrade? Do I need to manually create the db/current file? Supposedly , a format of 1 is from pre-svn 1.0. https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h - Formats 0, 1 and 2 were pre-1.0. Are we talking about the repository format or the FSFS format here? If repos/db/fs-type says fsfs then the repository format (repos/format) is probably 3 and you're talking about repos/db/format, yes? The distinction is important. In any case, 1.8 /should/ be able to dump an FSFSv1 repository, and the repos/db/current file should exists; it's been around since FSFSv1. You can try recreating it; the format is described here: https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure To find the youngest revision, look for the highest-numered file in repos/db/revs. If you're just going to dump the repository, it should be safe to set the next-node-id and next-copy-id to some large number, say 99; but I wouldn't recommend trying to commit to the repository. Please report if the above works or I'm just talking through my hat. :) -- Brane
RE: Dealing with very old repo format (version 1)
-Original Message- From: Joseph Bruni [mailto:jbr...@icloud.com] Sent: Tuesday, April 28, 2015 5:09 PM To: Andrew Reedick Cc: users@subversion.apache.org Subject: Re: Dealing with very old repo format (version 1) On Apr 28, 2015, at 2:03 PM, Andrew Reedick jreed...@incomm.com wrote: Does anyone have any tips on how to upgrade a very old repo? The db/format lists 1. A 1.8 svn client cannot hotcopy, dump or svnadmin upgrade such an old repo, all of which fail with svnadmin: E720002: Can't open file 'devel\db\current': The system cannot find the file specified. Do I need find a really old svn client (1.3?) and upgrade? Do I need to manually create the db/current file? Supposedly , a format of 1 is from pre-svn 1.0. https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h - Formats 0, 1 and 2 were pre-1.0. Hi Andrew, I'm guessing your old format was built using the BerkeleyDB backend since many of the earlist repos defaulted to BDB until FSFS came around. If you build your svn with BDB, does it still complain? Forgot to mention, db\fs-type is fsfs so BDB isn't (shouldn't) be an issuse. On the plus side, I found some ancient installers: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=469expandFolder=469folderID=11149
Re: Dealing with very old repo format (version 1)
On Apr 28, 2015, at 2:03 PM, Andrew Reedick jreed...@incomm.com wrote: Does anyone have any tips on how to upgrade a very old repo? The db/format lists 1. A 1.8 svn client cannot hotcopy, dump or svnadmin upgrade such an old repo, all of which fail with svnadmin: E720002: Can't open file 'devel\db\current': The system cannot find the file specified. Do I need find a really old svn client (1.3?) and upgrade? Do I need to manually create the db/current file? Supposedly , a format of 1 is from pre-svn 1.0. https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h - Formats 0, 1 and 2 were pre-1.0. Hi Andrew, I'm guessing your old format was built using the BerkeleyDB backend since many of the earlist repos defaulted to BDB until FSFS came around. If you build your svn with BDB, does it still complain? Regards, joseph
RE: Dealing with very old repo format (version 1)
-Original Message- From: Andrew Reedick [mailto:jreed...@incomm.com] Sent: dinsdag 28 april 2015 23:03 To: users@subversion.apache.org Subject: Dealing with very old repo format (version 1) Does anyone have any tips on how to upgrade a very old repo? The db/format lists 1. A 1.8 svn client cannot hotcopy, dump or svnadmin upgrade such an old repo, all of which fail with svnadmin: E720002: Can't open file 'devel\db\current': The system cannot find the file specified. Do I need find a really old svn client (1.3?) and upgrade? Do I need to manually create the db/current file? Supposedly , a format of 1 is from pre-svn 1.0. https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/re p os.h - Formats 0, 1 and 2 were pre-1.0. There are repository versions and database versions (format files are in repos/ and repos/db/). It looks like he is talking about the db format, which is documented in the filesystem backends. Bert
RE: Dealing with very old repo format (version 1)
-Original Message- From: Andrew Reedick [mailto:jreed...@incomm.com] On Apr 28, 2015, at 2:03 PM, Andrew Reedick jreed...@incomm.com wrote: Does anyone have any tips on how to upgrade a very old repo? The db/format lists 1. A 1.8 svn client cannot hotcopy, dump or svnadmin upgrade such an old repo, all of which fail with svnadmin: E720002: Can't open file 'devel\db\current': The system cannot find the file specified. Do I need find a really old svn client (1.3?) and upgrade? Do I need to manually create the db/current file? Supposedly , a format of 1 is from pre-svn 1.0. https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h - Formats 0, 1 and 2 were pre-1.0. Hi Andrew, I'm guessing your old format was built using the BerkeleyDB backend since many of the earlist repos defaulted to BDB until FSFS came around. If you build your svn with BDB, does it still complain? Forgot to mention, db\fs-type is fsfs so BDB isn't (shouldn't) be an issuse. On the plus side, I found some ancient installers: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=469expandFolder=469folderID=11149 Looks like the fsfs type was introduced in 1.1. However, a 1.1.4 client fails with svn: Can't open file 'devel/db/current': The system cannot find the file specified. And the 1.0.9 client fails with svn: Berkeley DB error while opening 'nodes' table for filesystem devel - Copy/db: No such file or directory Looks like I need a bigger hammer.
Re: Best version for RHEL7/CentOS 7?
On Tue, Apr 28, 2015 at 2:15 PM, Les Mikesell lesmikes...@gmail.com wrote: Can someone comment on the best version of subversion to run on CentOS7? The distribution supplies 1.7.14.I was thinking of using the packaged 1.8.x from Wandisco, but I don't see a mod_dav_svn here: http://opensource.wandisco.com/centos/7/svn-1.8/RPMS/x86_64/ Does that mean there is a problem building it or am I missing something? -- Les Mikesell lesmikes...@gmail.com In general, the CentOS releases will be based on more regression tested, stable source from RHEL. Even though I publish the tools to build backport SRPM's and RPM's myself, at https://github.com/nkadel/, I'd encourage stable, upstream tested tools where feasible. And I'd jump to 1.7.20, or even to the noticeable performance and integration of 1.8.13, only if I really need some of the new features. This is especially true of you have NFS or CIFS based home directories and will access them with 1.8.x on one upgraded system and 1.7.x on another system for the same working copy.
Dealing with very old repo format (version 1)
Does anyone have any tips on how to upgrade a very old repo? The db/format lists 1. A 1.8 svn client cannot hotcopy, dump or svnadmin upgrade such an old repo, all of which fail with svnadmin: E720002: Can't open file 'devel\db\current': The system cannot find the file specified. Do I need find a really old svn client (1.3?) and upgrade? Do I need to manually create the db/current file? Supposedly , a format of 1 is from pre-svn 1.0. https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_repos/repos.h - Formats 0, 1 and 2 were pre-1.0.
Re: Best version for RHEL7/CentOS 7?
On Tue, Apr 28, 2015 at 4:06 PM, Nico Kadel-Garcia nka...@gmail.com wrote: On Tue, Apr 28, 2015 at 2:15 PM, Les Mikesell lesmikes...@gmail.com wrote: Can someone comment on the best version of subversion to run on CentOS7? The distribution supplies 1.7.14.I was thinking of using the packaged 1.8.x from Wandisco, but I don't see a mod_dav_svn here: http://opensource.wandisco.com/centos/7/svn-1.8/RPMS/x86_64/ Does that mean there is a problem building it or am I missing something? In general, the CentOS releases will be based on more regression tested, stable source from RHEL. Even though I publish the tools to build backport SRPM's and RPM's myself, at https://github.com/nkadel/, I'd encourage stable, upstream tested tools where feasible. And I'd jump to 1.7.20, or even to the noticeable performance and integration of 1.8.13, only if I really need some of the new features. This is especially true of you have NFS or CIFS based home directories and will access them with 1.8.x on one upgraded system and 1.7.x on another system for the same working copy. I'd expect the wandisco packaged versions to have reasonable stability, and was hoping for something that would need nothing but 'yum update' to maintain for many years in the future - and would like to jump to 1.8 if possible.I see wandisco does have mod_dav_svn built for RHEL/Centos6 along with the 1.8 subversion rpms. Using CentOS 6.x would be an alternative, but I'd like to get as much life out of this system as possible. -- Les Mikesell lesmikes...@gmail.com
Best version for RHEL7/CentOS 7?
Can someone comment on the best version of subversion to run on CentOS7? The distribution supplies 1.7.14.I was thinking of using the packaged 1.8.x from Wandisco, but I don't see a mod_dav_svn here: http://opensource.wandisco.com/centos/7/svn-1.8/RPMS/x86_64/ Does that mean there is a problem building it or am I missing something? -- Les Mikesell lesmikes...@gmail.com
Re: Cannot checkout or clean up using 1.9 dev build
On 27 April 2015 at 21:35, Benjamin Fritz fritzophre...@gmail.com wrote: Apparently I'm not subscribed to get list emails; please CC me on future responses. I had to get this message from the archive :-) Branko Čibej wrote: On 27.04.2015 18:06, Benjamin Fritz wrote: I get the following error when I try to check out a working copy from my repository at work (exact path names obfuscated but length unchanged, in case it matters It probably does matter ... FWIW, I believe you did change the length of the file name, the workqueue record says 234 chars but the name in the record is 240; still, that shouldn't be an issue. Oops. You're right. My actual directory has only 3 characters where I replaced with Prog in the path string. Still, those 6 fewer characters are probably irrelevant. ), leaving a partially downloaded working copy: svn: E155009: Failed to run the WC DB work queue associated with 'C:\Project_Files\Proj_Dev\Prog_svn_1.9_cmdline', work item 2160 (file-install 234 Logical_Architecture/APP/App_PL_Verification/XXX/XXX_XXXs/XXX_7_APPDB_PROJ_PROG--0021_BE/APPDB_PROJ_PROG--0021.SUP/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021.SUP/XXX_APPDB_PROJ_PROG--002101.CRC 1 0 1 1) svn: E720123: The filename, directory name, or volume label syntax is incorrect. The full path of the file would be 281 characters long, which is more than Windows' limit of 260. But Subversion goes to a lot of trouble to avoid the path limit ... I wonder what's going on here. It seems Windows specific implementation of svn_stream__install_stream() doesn't prepend path with \\?\ for long names. Replacing svn_utf__win32_utf8_to_utf16() call with svn_io__utf8_to_unicode_longpath() should fix the problem, but I didn't try yet. Bert, is it intentional behavior or just small typo? -- Ivan Zhakov
