Re: Issue in commit: Can't open activity db: Unrecognized resolver error
Try figuring out what the error number is. (the error text comes from apr_os_strerror(), see there for pointers on how to interpret the error number) Daniel wrote on Thu, May 19, 2011 at 18:12:10 -0300: > In a working repository, I started to having the following error message: > > Commit > Commit failed (details follow): > Can't open activity db: Unrecognized resolver error > > I checked that svn/repo/dav and it has 777 permissions, then I chown all the > repo with 777 but still have the same error > > Any ideas? > > Note: the environment is Solaris > > Thanks, > Daniel
Re: fsverify.py unable to fix invalid svndiff header
> Steinar Bang : > I've been looking to see if there are any tools that can slurp out the > history of a repository, using the svn client API. But all repository > conversion seems to be based on "svnadmin dump". And "svnadmin dump" > croaks on all revisions later than 682...:-/ svnsync and svnrdump, sounds like if they implement part of this: they use the client API to pull down revisions for dump or export http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svnsync http://thread.gmane.org/gmane.comp.version-control.subversion.user/99717 nntp://news.gmane.org/gmane.comp.version-control.subversion.user/99717 But they both stop on revision 683, and they refuse to start on any revision succeeding it. :-/ Since it is possible to check out the parts/paths in the repository that are interesting to me (my home directory and its branches), it would have been nice if it was possible to tell these tools to make a clone of a particular part of the repository into a new repository (or a dumpfile for that matter). I don't care if revision numbers are preserved or not, only that the history is preserved (and preferrably with the branching information preserved). Failing that, is it possible to make all of the dump/export programs work on revisions following 683? I saw something in one of the google hits about "truncating the revision", and I tried to do so in one experiment. But as far as I can recall dumping later versions than 683 still failed. (I don't need that part of the repository tree that is in 683 and surrounding revisions, so any fix that loses it and lets me recover what is important to me, is ok by me) Thanks!
Re: fsverify.py unable to fix invalid svndiff header
svnsync,svnrdump use the svn_ra_* API, not the svn_client_* API. You should be able to use either of them if you install authz on your repository such that *any* paths touched in r683 are unreadable by the user svnsync/svnrdump connect as. Steinar Bang wrote on Sat, May 21, 2011 at 18:26:30 +0200: > > Steinar Bang : > > > I've been looking to see if there are any tools that can slurp out the > > history of a repository, using the svn client API. But all repository > > conversion seems to be based on "svnadmin dump". And "svnadmin dump" > > croaks on all revisions later than 682...:-/ > > svnsync and svnrdump, sounds like if they implement part of this: they > use the client API to pull down revisions for dump or export > > http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svnsync > http://thread.gmane.org/gmane.comp.version-control.subversion.user/99717 > nntp://news.gmane.org/gmane.comp.version-control.subversion.user/99717 > > But they both stop on revision 683, and they refuse to start on any > revision succeeding it. :-/ > > Since it is possible to check out the parts/paths in the repository that > are interesting to me (my home directory and its branches), it would > have been nice if it was possible to tell these tools to make a clone of > a particular part of the repository into a new repository (or a dumpfile > for that matter). > > I don't care if revision numbers are preserved or not, only that the > history is preserved (and preferrably with the branching information > preserved). > > Failing that, is it possible to make all of the dump/export programs > work on revisions following 683? > > I saw something in one of the google hits about "truncating the > revision", and I tried to do so in one experiment. But as far as I can > recall dumping later versions than 683 still failed. > > (I don't need that part of the repository tree that is in 683 and > surrounding revisions, so any fix that loses it and lets me recover what > is important to me, is ok by me) > > Thanks! >
Re: Properties lost on checkin
Does http://subversion.tigris.org/issues/show_bug.cgi?id=3884 describe
the problem you were seeing?
Christoph Bartoschek wrote on Thu, May 19, 2011 at 11:12:01 +0200:
> Hi,
>
> do I have to open an issue for this?
>
> Am 17.05.2011 13:24, schrieb Daniel Shahaf:
> >I committed
> >
> >http://svn.apache.org/viewvc?view=rev&revision=r1104092
> >
> >before I saw this mail from you.
> >
> >(please add dev@ to CC if needed)
> >
> >Christoph Bartoschek wrote on Tue, May 17, 2011 at 11:06:47 +0200:
> >>Hi,
> >>
> >>I have a small script that reproduces the problem:
> >>
> >>dir=$PWD
> >>
> >>svnadmin create a
> >>svnadmin create b
> >>
> >>svn co file://${dir}/a ca1
> >>svn co file://${dir}/b cb1
> >>
> >> cd ${dir}/ca1
> >> touch file
> >>svn add file
> >>svn ci -m "Added file"
> >> ln -sf file link
> >>svn add link
> >>svn ci -m "Added link"
> >>
> >> cd ${dir}/cb1
> >>svn merge -r 0:1 file://${dir}/a .
> >>svn ci -m "Merged revision 1"
> >>svn up
> >>svn merge -r 1:2 file://${dir}/a .
> >>svn ci -m "Merged revision 2"
> >>
> >> cd ${dir}
> >>svn co file://${dir}/b cb2
> >>
> >>ls -l cb1
> >>ls -l cb2
> >>
> >>Am 17.05.2011 12:00, schrieb Daniel Shahaf:
> >>>CC += dev@
> >>>
> >>>I haven't tried with 1.6.x, but merging a symlink-add from a foreign
> >>>repository does result in bogus state with current trunk:
> >>>
> >>>[[[
> >>>% $svn merge -c r922451
> >>>https://svn.apache.org/repos/asf/subversion/site/publish/
> >>>--- Merging (from foreign repository) r922451 into '.':
> >>>Afaq.en.html
> >>>% $svn st
> >>>~M faq.en.html
> >>>% $svn info faq.en.html
> >>>Path: faq.en.html
> >>>Name: faq.en.html
> >>>Working Copy Root Path: /tmp/svn/wc1
> >>>URL: file:///tmp/svn/r1/trunk/faq.en.html
> >>>Repository Root: file:///tmp/svn/r1
> >>>Repository UUID: 0d8f1070-806c-11e0-a89b-a382cea1935c
> >>>Node Kind: file
> >>>Schedule: add
> >>>
> >>>% file faq.en.html
> >>>faq.en.html: ASCII text, with no line terminators
> >>>%
> >>>]]]
> >>>
> >>>
> >>>I'll forward this to dev@ (CC'ing you).
> >>>
> >>>
> >>>Christoph Bartoschek wrote on Tue, May 17, 2011 at 09:24:30 +0200:
> Hi,
>
> I have a workarea where I merged in some changes from a completely
> different repository. One of the changes was the creation of a link.
> After checking in I see that the link is ok in my workarea but not in
> any other workarea.
>
> This due to the missing svn:special keyword that was not checked in. How
> can this happen?
>
> The following shows inconsistent behaviour in my opinion. How can this
> be explained:
>
> esquad$ svn proplist -v tm.h
> Properties on 'tm.h':
> svn:special
> *
>
> esquad$ svn info tm.h
> Path: tm.h
> Name: tm.h
> URL: https://server/trunk/include/tm/tm.h
> Repository Root: https://server
> Repository UUID: 608964b8-1798-474c-b2d9-552667dc04a5
> Revision: 27
> Node Kind: file
> Schedule: normal
> Last Changed Author: christoph
> Last Changed Rev: 26
> Last Changed Date: 2011-05-16 18:11:17 -0400 (Mon, 16 May 2011)
> Text Last Updated: 2011-05-17 02:51:09 -0400 (Tue, 17 May 2011)
> Checksum: 1a7ff762ceabb28ca8865f9b0ba377ff
>
> esquad$ svn proplist -v https://server/trunk/include/tm/tm.h
>
> esquad$ svn diff -r HEAD tm.h
>
>
> This shows that locally the svn:special keyword is set but not on the
> server. But svn does not see any difference. Is this a known bug? Or
> how can I get the missing keywords checked in?
>
>
> Christoph
> >>
>
Re: Empty revisions causing repository failures
Ulrich Eckhardt wrote on Thu, May 19, 2011 at 10:55:59 +0200: > On Wednesday 18 May 2011, Christian Gils wrote: > > I've version 1.5.6 using FSFS stored on ext3 (RHEL 5.4). The repository > > contains about 39k revisions. Revisions 0-36672 are fine and dump > > without any problems. Revisions 36673-8 fail to verify and give the > > following error: > > > > svnadmin: Revision file lacks trailing newline > > > > The same revisions fail to dump and give the following error: > > > > svnadmin: Can't read length line in file 'repo/db/revs/36/3667x > > > [...] > > 36679-HEAD seem to be fine as users have been committing and checking > > out since then. A couple of days ago, however, local checkouts started > > failing with the following error (the rev file listed is going to be one > > of the failing revisions): > > > > svn: Can't read length line in file '/data3/tmp/repo/db/revs/36/3667x' > > > > It looks like certain checkouts hit a file which prompts svn to try and > > read those revisions and subsequently fail. > > If a commit doesn't change a file, the data in a previous commit will be > referenced instead, so that it avoids writing the same data over and over > again. When reading, it then looks in previous revisions to locate the file > if > necessary. That explains why you can access some parts but not those that > were > changed in the lost range. > > > As a result we have a > > project which is unusable at the moment. Verification and dumping from > > 36679-HEAD will proceed until it hits a reference back to one of the > > borked revisions and them terminate. I can't even dump both halves of > > the repo and reimport omitting 36673-36678. > > IIRC, SVN won't touch these files once they were written. Files under revs/** are never changed once they're written. (packing concatenates files but doesn't change their contents) > That means that you > can copy just those files from an old backup without disturbing any earlier > or > later revisions. Of course you should back up your life data before and > validate the results afterwards. > > > I'm kind of stuck as to how to fix this. Can I try to insert mocked-up > > empty revisions in place of the zeroed ones so that svn can proceed with > > dumping the more recent half of the repository or is there a better way > > to do this? > > I don't think that works because dumping writes full files, but in order to > get those it might have to read multiple deltas (revisions) from the > repository. If these are not there, you can't restore the full file content. > FTR, 'svnadmin dump' does take a --deltas option.
Re: Properties lost on checkin
Am 21.05.2011 19:12, schrieb Daniel Shahaf: Does http://subversion.tigris.org/issues/show_bug.cgi?id=3884 describe the problem you were seeing? Yes. But I wonder why file sees a text file for you. In the repository where I do the merge I see a symlink. I get a normal file only after a new checkout or update. Christoph
Re: fsverify.py unable to fix invalid svndiff header
> Daniel Shahaf : > Steinar Bang wrote on Sat, May 21, 2011 at 18:26:30 +0200: [snip! svnsync and svnrdump] >> .., it would have been nice if it was possible to tell these tools to >> make a clone of a particular part of the repository into a new >> repository (or a dumpfile for that matter). > You should be able to use either of them if you install authz on your > repository such that *any* paths touched in r683 are unreadable by the > user svnsync/svnrdump connect as. I tried adding this to /svn/conf/authz: [/trunk/someprog] * = (everything else in the file are comments) But both tools still break at revision 683, which is in the path /trunk/someprog/metamodeller. svnsync breaks with: ... Committed revision 681. Copied properties for revision 681. Transmitting file data . Committed revision 682. Copied properties for revision 682. Transmitting file data svnsync: Error while replaying commit svnrdump breaks with: ... * Dumped revision 680. * Dumped revision 681. * Dumped revision 682. svnrdump: E210008: Error while replaying commit I was using the svn+ssh method to access the repo. Do I need http access to get the effect you were suggesting? The box at the bottom of this web page would seem to indicate that I need the http method: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html >From that box: "As the server generates the large response, there's no way it can resend an authentication challenge when it reaches the special subdirectory; thus the subdirectory is skipped altogether"
Re: fsverify.py unable to fix invalid svndiff header
> Steinar Bang : > I tried adding this to /svn/conf/authz: > [/trunk/someprog] > * = > (everything else in the file are comments) > But both tools still break at revision 683, which is in the path > /trunk/someprog/metamodeller. [snip!] > I was using the svn+ssh method to access the repo. Do I need http > access to get the effect you were suggesting? No I don't. svn+ssh works fine for this. But I forgot the little part at the start of this page: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html "If you're using svnserve, you need to make the authz-db variable (within svnserve.conf) point to your access rules file." So I uncommented this line in the sample svnserve.conf: # authz-db = authz And then svnsync pulled the entire repo. Or at least: it didn't stop at revision 683. But the resulting repo doesn't seem to be functional: sb@edwards:~$ svn ls file:///tmp/newrepo/svn/ sb@edwards:~$ svn ls file:///tmp/newrepo/svn/trunk svn: URL 'file:///tmp/newrepo/svn/trunk' non-existent in that revision
Re: fsverify.py unable to fix invalid svndiff header
> Steinar Bang : > Steinar Bang : >> I tried adding this to /svn/conf/authz: >> [/trunk/someprog] >> * = >> (everything else in the file are comments) [snip!] > So I uncommented this line in the sample svnserve.conf: > # authz-db = authz > And then svnsync pulled the entire repo. Or at least: it didn't stop at > revision 683. > But the resulting repo doesn't seem to be functional: > sb@edwards:~$ svn ls file:///tmp/newrepo/svn/ > sb@edwards:~$ svn ls file:///tmp/newrepo/svn/trunk > svn: URL 'file:///tmp/newrepo/svn/trunk' non-existent in that revision More fine print I didn't read, in: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html "By default, nobody has any access to the repository at all. That means that if you're starting with an empty file, you'll probably want to give at least read permission to all users at the root of the repository." So now the /svn/conf/authz file contains: [/] * = r [/trunk/someprog] * = And then I'm able to see contents in the cloned repository: sb@edwards:~$ svn ls file:///tmp/newrepo/svn/ branches/ tags/ trunk/ Thanks, Daniel!
