Re: Cannot checkout or clean up using 1.9 dev build
On 27 April 2015 at 21:35, Benjamin Fritz 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
Re: Cannot checkout or clean up using 1.9 dev build
On 28 April 2015 at 10:07, Ivan Zhakov wrote: > On 27 April 2015 at 21:35, Benjamin Fritz 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: Cannot checkout or clean up using 1.9 dev build
On Apr 28, 2015 8:02 AM, "Ivan Zhakov" 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
Re: Cannot checkout or clean up using 1.9 dev build
On 28 April 2015 at 16:15, Benjamin Fritz wrote: > > On Apr 28, 2015 8:02 AM, "Ivan Zhakov" 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
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ß
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
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 2:15 PM, Les Mikesell 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.
Re: Dealing with very old repo format (version 1)
> On Apr 28, 2015, at 2:03 PM, 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." > 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: 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 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=469&expandFolder=469&folderID=11149
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 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=469&expandFolder=469&folderID=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 4:06 PM, Nico Kadel-Garcia wrote: > On Tue, Apr 28, 2015 at 2:15 PM, Les Mikesell 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
Re: Dealing with very old repo format (version 1)
On Tue, Apr 28, 2015 at 5:03 PM, 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." 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 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 /db/fs-type says "fsfs" then the repository format (/format) is probably 3 and you're talking about /db/format, yes? The distinction is important. In any case, 1.8 /should/ be able to dump an FSFSv1 repository, and the /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 /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)
On 29.04.2015 05:09, Nico Kadel-Garcia wrote: > On Tue, Apr 28, 2015 at 5:03 PM, 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." > 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
