Re: svndumpfilter help
On Feb 3, 2016, at 10:49 AM, Eric Antonio Maquiling wrote: > I have a new problem. Not a problem with the software I think this is > sysadmin/user error. > > I've read the docs and examples on how to use svnadmin dump and svndumpfilter. > > I'm familiar with dumps and loads. But I have a new task appointed to me. > > I have a directory structure that looks like this: > > svn://x.x.x.x/mainproject/branch/this_new_stuff > > Developers want to take /this_new_stuff as a dump, and create a new repo so > it'll look like this: > > svn://x.x.x.x/this_new_stuff > > So far so good, I'll try svndumpfilter. > > So I do: > svnadmin dump mainproject > mainproject.dump > svndumpfilter include this_new_stuff > new_stuff_only.dmp > svnadmin create new_stuff > cd new_stuff > svnadmin load . < ../new_stuff_only.dmp > ... > ... lots of messages that it is loading > ... it's going good, I'm getting stoked it is working > ... > ... whew, it's a lot, almost done > > done. > > Now I then go to my PC and do a tortoise browse svn://x.x.x.x/this_new_stuff > > And it is EMPTY. If the old repository root is svn://x.x.x.x/mainproject and the stuff you want to include in the dump is in branch/this_new_stuff in the old repository, then you need to run: svnadmin dump mainproject > mainproject.dump svndumpfilter include branch/this_new_stuff < mainproject.dump > new_stuff_only.dmp If branch/this_new_stuff was ever elsewhere in the repository (for example, if it was at some point in the past moved from somewhere/else/in/the/repo), then you need to include that location too.
Subversion crashes on list with an empty format 3 repo
Hi folks, Subversion advised me to report this. The following command was performed: svn --non-interactive list file:///D:/Entwicklung/Projekte/maven-wagon/wagon-providers/wagon-scm/src/test/resources/test-repo-svn The repo is available here [1], the crash files are here [2]. The issue can always be reproduced, it does not require to run the tests with Maven on Maven Wagon. My environment is: Microsoft Windows [Version 10.0.10586] svn, version 1.9.3 (r1718519) compiled Dec 22 2015, 09:12:06 on x86_64-microsoft-windows6.2.9200 [1] https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=tree;f=wagon-providers/wagon-scm/src/test/resources/test-repo-svn;h=8c391643aeb6cbdce7447de8d86c5ae9b3b0c31a;hb=HEAD [2] http://home.apache.org/~michaelo/svn-crash-2016-02-05/ Michael
Re: svndumpfilter help
> >If the old repository root is svn://x.x.x.x/mainproject and the stuff you want >to include in the dump is in branch/this_new_stuff in the old repository, then >you need to run: > >svnadmin dump mainproject > mainproject.dump >svndumpfilter include branch/this_new_stuff < mainproject.dump > >new_stuff_only.dmp Correct, it was in branch/this_new_stuff I thought I had tried that...did so many dumps to try to get it working. Let me look at the bash history file but I'll just go ahead and try that one again, do another create and import. I'll let you guys know!! :) Thanks! -- eric
Re: svndumpfilter help
> >svnadmin dump mainproject > mainproject.dump >svndumpfilter include branch/this_new_stuff < mainproject.dump > >new_stuff_only.dmp I guess I did try it bofore and I got this error: Revision 2003 committed as 2003. Revision 2004 committed as 2004. Revision 2005 committed as 2005. Revision 2006 committed as 2006. svndumpfilter: Invalid copy source path '/trunk' The repo looks like this: svn://x.x.x.x/mainproject/branches/ svn://x.x.x.x/mainproject/truck/ under branches: /branches/this_is_what_we_want You see, the developers have been using this branch for so long they don't want to mess up the history on the trunk. So for historical reasons, they just want branches/this_is_what_we_want as a new repo If they need to see some older stuff (probably not), they'll just go and browse the old trunck. -- eric
Re: Subversion crashes on list with an empty format 3 repo
On 5 February 2016 at 21:38, Michael Osipov wrote: > Hi folks, > > Subversion advised me to report this. > > The following command was performed: > svn --non-interactive list > file:///D:/Entwicklung/Projekte/maven-wagon/wagon-providers/wagon-scm/src/test/resources/test-repo-svn > > The repo is available here [1], the crash files are here [2]. > The issue can always be reproduced, it does not require to run the tests > with Maven on Maven Wagon. > I cannot reproduce: [[[ svn --non-interactive file:///D:/Ivan/temp/repos/test-repo-svn dummy C:\Program Files\VisualSVN Server\bin>svn --version svn, version 1.9.3 (r1718519) compiled Dec 15 2015, 11:23:08 on x86-microsoft-windows6.1.7601 Copyright (C) 2015 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.3.8 (compiled with 1.3.8) - handles 'http' scheme - handles 'https' scheme The following authentication credential caches are available: * Wincrypt cache in C:\Users\ivan\AppData\Roaming\Subversion ]]] -- Ivan Zhakov
Re: Subversion crashes on list with an empty format 3 repo
Am 2016-02-05 um 20:31 schrieb Ivan Zhakov: On 5 February 2016 at 21:38, Michael Osipov wrote: Hi folks, Subversion advised me to report this. The following command was performed: svn --non-interactive list file:///D:/Entwicklung/Projekte/maven-wagon/wagon-providers/wagon-scm/src/test/resources/test-repo-svn The repo is available here [1], the crash files are here [2]. The issue can always be reproduced, it does not require to run the tests with Maven on Maven Wagon. I cannot reproduce: [[[ svn --non-interactive file:///D:/Ivan/temp/repos/test-repo-svn dummy C:\Program Files\VisualSVN Server\bin>svn --version svn, version 1.9.3 (r1718519) compiled Dec 15 2015, 11:23:08 on x86-microsoft-windows6.1.7601 After further testing, I think I know why it does not fail for you. You have downloaded a tarball snapshot of the repo via Gitweb. I have retried with that one and Subversion does not crash. Aifter that, I ran SHA1 on all files, cloned via Git and from the tarball, they are different because Git transforms the db files and aligned the line ending. svnadmin verify crashes too. These might shred the repo: core.autocrlf=true core.eol=native core.safecrlf=true I have uploaded both repos to [1] as ZIP files. Can you kindly retry with a cloned repo or the ZIP files and report back? [1] http://home.apache.org/~michaelo/svn-crash-2016-02-05/ Michael
Re: Subversion crashes on list with an empty format 3 repo
On 5 February 2016 at 23:48, Michael Osipov wrote: > Am 2016-02-05 um 20:31 schrieb Ivan Zhakov: >> >> On 5 February 2016 at 21:38, Michael Osipov wrote: >>> >>> Hi folks, >>> >>> Subversion advised me to report this. >>> >>> The following command was performed: >>> svn --non-interactive list >>> >>> file:///D:/Entwicklung/Projekte/maven-wagon/wagon-providers/wagon-scm/src/test/resources/test-repo-svn >>> >>> The repo is available here [1], the crash files are here [2]. >>> The issue can always be reproduced, it does not require to run the tests >>> with Maven on Maven Wagon. >>> >> I cannot reproduce: >> [[[ >> svn --non-interactive file:///D:/Ivan/temp/repos/test-repo-svn >> dummy >> >> C:\Program Files\VisualSVN Server\bin>svn --version >> svn, version 1.9.3 (r1718519) >> compiled Dec 15 2015, 11:23:08 on x86-microsoft-windows6.1.7601 > > > After further testing, I think I know why it does not fail for you. You have > downloaded a tarball snapshot of the repo via Gitweb. I have retried with > that one and Subversion does not crash. Aifter that, I ran SHA1 on all > files, cloned via Git and from the tarball, they are different because Git > transforms the db files and aligned the line ending. > > svnadmin verify crashes too. > > These might shred the repo: > core.autocrlf=true > core.eol=native > core.safecrlf=true > > I have uploaded both repos to [1] as ZIP files. > > Can you kindly retry with a cloned repo or the ZIP files and report back? > > [1] http://home.apache.org/~michaelo/svn-crash-2016-02-05/ > I downloaded archive and now I'm getting error about wrong FS type as expected: [[[ C:\Program Files\VisualSVN Server\bin> --non-interactive file:///D:/Ivan/temp/repos/test-repo-svn svn: E170013: Unable to connect to a repository at URL 'file:///D:/Ivan/temp/repos/test-repo-svn' svn: E180001: Unable to open repository 'file:///D:/Ivan/temp/repos/test-repo-svn' 'vn: E160033: Invalid name for FS type 'fsfs ]]] -- Ivan Zhakov
Problem setting up authz on svnserve
Hello, I am a newbie to using authz, and am trying to set it up for the first time. For reasons I don't understand, I can't seem to get it working. I am using svnserve and fsfs, subversion 1.8.10 for both server and client for testing. My svnserve.conf setup is: anon-access = none password-db = passwd authz-db = authz Initial contents of my authz file (just trying to get *any* authz setup to work at this point): [/] * = rw With this setup, here is what my client says when I try to do an svn ls: $ svn ls svn://my_repos svn: E210002: Unable to connect to a repository at URL 'svn://my_repos' svn: E210002: Network connection closed unexpectedly I have tried giving an absolute path to authz, checking it into the repository and giving a URL but the result is the same each time. As soon as I uncomment the authz-db line in svnserve.conf any access to the repo results in the above error. When I comment the authz-db line again, the problem goes away. The permissions, ownership, and location of my authz file match those of my passwd file, and svnserve is accessing the passwd file ok. Errors I see in my svnserve.log that *may* be related are: 28207 2016-02-03T18:31:50.113582Z xxx.xx.xx.xxx - - ERR - 0 210002 Network connection closed unexpectedly 28540 2016-02-03T18:50:55.871361Z xxx.xx.xx.xxx - - ERR - 0 104 Can't read from connection: Connection reset by peer But these only occurred rarely, and not each time I tried to access the repo and got the above client error. At this point I'm stuck. Am I doing anything obviously wrong? Any suggestions on how I can debug this? Many thanks! Rick Varney
Re: Subversion crashes on list with an empty format 3 repo
Am 2016-02-05 um 22:10 schrieb Ivan Zhakov: On 5 February 2016 at 23:48, Michael Osipov wrote: Am 2016-02-05 um 20:31 schrieb Ivan Zhakov: On 5 February 2016 at 21:38, Michael Osipov wrote: Hi folks, Subversion advised me to report this. The following command was performed: svn --non-interactive list file:///D:/Entwicklung/Projekte/maven-wagon/wagon-providers/wagon-scm/src/test/resources/test-repo-svn The repo is available here [1], the crash files are here [2]. The issue can always be reproduced, it does not require to run the tests with Maven on Maven Wagon. I cannot reproduce: [[[ svn --non-interactive file:///D:/Ivan/temp/repos/test-repo-svn dummy C:\Program Files\VisualSVN Server\bin>svn --version svn, version 1.9.3 (r1718519) compiled Dec 15 2015, 11:23:08 on x86-microsoft-windows6.1.7601 After further testing, I think I know why it does not fail for you. You have downloaded a tarball snapshot of the repo via Gitweb. I have retried with that one and Subversion does not crash. Aifter that, I ran SHA1 on all files, cloned via Git and from the tarball, they are different because Git transforms the db files and aligned the line ending. svnadmin verify crashes too. These might shred the repo: core.autocrlf=true core.eol=native core.safecrlf=true I have uploaded both repos to [1] as ZIP files. Can you kindly retry with a cloned repo or the ZIP files and report back? [1] http://home.apache.org/~michaelo/svn-crash-2016-02-05/ I downloaded archive and now I'm getting error about wrong FS type as expected: [[[ C:\Program Files\VisualSVN Server\bin> --non-interactive file:///D:/Ivan/temp/repos/test-repo-svn svn: E170013: Unable to connect to a repository at URL 'file:///D:/Ivan/temp/repos/test-repo-svn' svn: E180001: Unable to open repository 'file:///D:/Ivan/temp/repos/test-repo-svn' 'vn: E160033: Invalid name for FS type 'fsfs ]]] We know now that the repo is mangled. The output of the last line is broken btw. It should read "svn:... 'fsfs'" but it reads "'vn:...'fsfs". Shall a I create a JIRA issue for that? I have unzipped the repo on: FreeBSD bsd10 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r28: Wed Aug 12 15:26:37 UTC 2015 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 and I receive the very same error as you do. Additionally, I just created a VM with Windows 7 SP1 32 bit and installed Subversion 1.9.3 and the test repo. The svn client crashes here too. I do not understand why it is not failing for you. Can you retry with the binaries provided by CollabNet? Or any other idea why there is a disparity? Addendum: I have tried the MaxSVN distro recently announced on this list: D:\Entwicklung\Projekte\test-repo-svn>C:\Users\mosipov\Documents\maxsvn_1.9.3-1\svn --version svn, version 1.9.3 (r1718519) compiled Jan 19 2016, 21:32:35 on x86_64-microsoft-windows10.0.10240 ... The following authentication credential caches are available: * Wincrypt cache in C:\Users\mosipov\AppData\Roaming\Subversion D:\Entwicklung\Projekte\test-repo-svn>C:\Users\mosipov\Documents\maxsvn_1.9.3-1\svn ls file:///D:/Entwicklung/Projekte/test-repo-svn svn: E170013: Unable to connect to a repository at URL 'file:///D:/Entwicklung/Projekte/test-repo-svn' svn: E180001: Unable to open repository 'file:///D:/Entwicklung/Projekte/test-repo-svn' 'vn: E160033: Unknown FS type 'fsfs Are the CollabNet binaries incorrectly compiled? Michael
Re: Subversion crashes on list with an empty format 3 repo
Am 2016-02-05 um 22:10 schrieb Ivan Zhakov: On 5 February 2016 at 23:48, Michael Osipov wrote: Am 2016-02-05 um 20:31 schrieb Ivan Zhakov: On 5 February 2016 at 21:38, Michael Osipov wrote: Hi folks, Subversion advised me to report this. The following command was performed: svn --non-interactive list file:///D:/Entwicklung/Projekte/maven-wagon/wagon-providers/wagon-scm/src/test/resources/test-repo-svn The repo is available here [1], the crash files are here [2]. The issue can always be reproduced, it does not require to run the tests with Maven on Maven Wagon. I cannot reproduce: [[[ svn --non-interactive file:///D:/Ivan/temp/repos/test-repo-svn dummy C:\Program Files\VisualSVN Server\bin>svn --version svn, version 1.9.3 (r1718519) compiled Dec 15 2015, 11:23:08 on x86-microsoft-windows6.1.7601 After further testing, I think I know why it does not fail for you. You have downloaded a tarball snapshot of the repo via Gitweb. I have retried with that one and Subversion does not crash. Aifter that, I ran SHA1 on all files, cloned via Git and from the tarball, they are different because Git transforms the db files and aligned the line ending. svnadmin verify crashes too. These might shred the repo: core.autocrlf=true core.eol=native core.safecrlf=true I have uploaded both repos to [1] as ZIP files. Can you kindly retry with a cloned repo or the ZIP files and report back? [1] http://home.apache.org/~michaelo/svn-crash-2016-02-05/ I downloaded archive and now I'm getting error about wrong FS type as expected: [[[ C:\Program Files\VisualSVN Server\bin> --non-interactive file:///D:/Ivan/temp/repos/test-repo-svn svn: E170013: Unable to connect to a repository at URL 'file:///D:/Ivan/temp/repos/test-repo-svn' svn: E180001: Unable to open repository 'file:///D:/Ivan/temp/repos/test-repo-svn' 'vn: E160033: Invalid name for FS type 'fsfs ]]] Picking up my previous response, I just tried binaries from VisualSVN (probably the one you are using) and from SlikSVN. Both are working...is that now an issue I have to raise with CollabNet or some hidden bug in Subversion itself? Michael
Re: svndumpfilter help
On Feb 5, 2016, at 1:04 PM, Eric Antonio Maquiling wrote: >> svnadmin dump mainproject > mainproject.dump >> svndumpfilter include branch/this_new_stuff < mainproject.dump > >> new_stuff_only.dmp > > I guess I did try it bofore and I got this error: > > Revision 2003 committed as 2003. > Revision 2004 committed as 2004. > Revision 2005 committed as 2005. > Revision 2006 committed as 2006. > svndumpfilter: Invalid copy source path '/trunk' > > The repo looks like this: > > svn://x.x.x.x/mainproject/branches/ > svn://x.x.x.x/mainproject/truck/ > under branches: > /branches/this_is_what_we_want > > > You see, the developers have been using this branch for so long they don't > want > to mess up the history on the trunk. So for historical reasons, they just > want > branches/this_is_what_we_want as a new repo > > If they need to see some older stuff (probably not), they'll just go and > browse > the old trunck. So as I said, if the thing you want to extract from the dump was originally copied from elsewhere in the repository (as, in your case, your branch was at one point copied from trunk), you have to extract that other place (i.e. trunk) as well. Here's the same question asked before, and some more suggestions: https://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&dsMessageId=517906
