"svnlook pl --revprop" does not work on transactions?
Hi all,
It seems that I encountered a bug in 'svnlook pl --revprop': it fails with
the following message:
$ svnlook pl --revprop -t 10547-86b /svn/test-svn
svnlook: Invalid revision number '-1'
Observed with Subversion 1.6.6. Looks like offending code is this block in
do_plist():
==
if (path != NULL)
...
else
{
SVN_ERR(svn_fs_revision_proplist(&props, c->fs, c->rev_id, pool));
revprop = TRUE;
}
==
Note that it always uses svn_fs_revision_proplist(), even when '-t TXN' is
passed. In this case, c->rev_id == SVN_INVALID_REVNUM (-1), and
svn_fs_revision_proplist() rightfully fails.
Shouldn't it be using svn_fs_txn_proplist() instead, just as
get_property() chooses between svn_fs_txn_prop() and
svn_fs_revision_prop()?
This conditional is still in /trunk, so most likely, bug is also
reproducible with top-of-trunk Subversion.
Regards,
Alexey.
signature.asc
Description: This is a digitally signed message part.
Managing Vendor Branches
I've recently needed to track changes for vendor code drops, so I read the SVN book's vendor branches chapter. But I'm not entirely happy with part of the procedure, so I'd like to talk it out and, I hope, find a better way. The part I hope to improve is when I have a versioned code drop in the /vendor directory, then the vendor provides a new code drop. The SVN book suggests that I should copy the new files over top of the files in my working copy. Then I need to SVN add and delete as needed. I saw there's a script to ease this process, but I still feel that this should be easier. It seems to me that comparing two trees, even unrelated trees, is something SVN is very good at. So if I have /vendor/code-drop-v1 and /vendor/code-drop-v2, then it seems SVN should be able to derive the changes between the two and apply those changes to my working copy. Can I do this?
"svnlook pl --revprop" does not work on transactions?
Hi all,
It seems that I encountered a bug in 'svnlook pl --revprop': it fails with
the following message:
$ svnlook pl --revprop -t 10547-86b /svn/test-svn
svnlook: Invalid revision number '-1'
Observed with Subversion 1.6.6. Looks like offending code is this block in
do_plist():
==
if (path != NULL)
...
else
{
SVN_ERR(svn_fs_revision_proplist(&props, c->fs, c->rev_id, pool));
revprop = TRUE;
}
==
Note that it always uses svn_fs_revision_proplist(), even when '-t TXN' is
passed. In this case, c->rev_id == SVN_INVALID_REVNUM (-1), and
svn_fs_revision_proplist() rightfully fails.
Shouldn't it be using svn_fs_txn_proplist() instead, just as
get_property() chooses between svn_fs_txn_prop() and
svn_fs_revision_prop()?
This conditional is still in /trunk, so most likely, bug is also
reproducible with top-of-trunk Subversion.
Regards,
Alexey.
Re: Tree conflict - svn status cannot show?
On 26 Feb 2010, at 13:01, Stefan Sperling wrote: > On Fri, Feb 26, 2010 at 12:05:52AM +, Barry Scott wrote: > j >> On 25 Feb 2010, at 23:18, Stefan Sperling wrote: >> >>> On Thu, Feb 25, 2010 at 10:30:18PM +, Barry Scott wrote: I starting to see failures to commit because of tree conflicts. svn status does not seem to show tree conflicts. >>> >>> It sure does. See examples here: >>> http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html >> >> We notice tree conflict after folder moves. Not seen one for a file move yet. >> This example only about file issues not folder issues. >> >>> Did I miss the way to find the tree conflicts? >>> >>> Not sure. What commands are you running and what output are you seeing? >> >> svn st -q >> >> and the output is blank. >> >> (I ran svn st -q after pysvn workbench failed to show anything problems.) > > What version of svn? Below 1.6.3? Some at 1.6.5 others at 1.5.4. > If so, this could be http://subversion.tigris.org/issues/show_bug.cgi?id=3382 > which was fixed in 1.6.3. ok. I'll make sure everybody is updated to this version of better. > > If this is not the problem, please try to come up with a script that > others can use to reproduce the problem, starting from an empty > repository. Will do if I see this again. Barry
Re: Infamous "Item is not readable" for svn log
> You can also put them both on Apache, then there's not that much > confusion. That's how we do it: two Location blocks in Apache, both > backed by the same repository: Hrm, I was kind of hoping to avoid using httpd.
Re: Infamous "Item is not readable" for svn log
On Fri, Feb 26, 2010 at 11:44 PM, David Brodbeck wrote: > On Feb 26, 2010, at 2:03 PM, Bob Archer wrote: >> Baring that setting up apache for anon requests and svn for authenticated. > > That would also work. In our case we didn't really want the added complexity > of Apache -- plus I was worried about user confusion. I already have a fair > number of people who get http: and svn: mixed up from time to time. Having > http: work in some situations but not others would just add to their > perplexity. You can also put them both on Apache, then there's not that much confusion. That's how we do it: two Location blocks in Apache, both backed by the same repository: - http://svn.example.com/public_svn: the anonymously accessible one. Goes over plain http, doesn't require authentication, but uses an authz file to limit the paths that can be read. - https://svn.example.com/svn: the "real" one for the developers. Goes over https, requires authentication, and doesn't use an authz file (allowing us to set "SVNPathAuthz off", which avoids the performance loss normally associated with this setup). Of course you can also have them both over https (it doesn't really hurt the anonymous one). Johan
Re: Infamous "Item is not readable" for svn log
>> I think setting up a guest username with no password is the easiest way to >> go. > > That's how we're doing it on our repository. It's a little clumsy, but > workable for our user population. You mean like I've done it? e.g.: svn checkout svn://clanwtf.net/repos/ioUrT-server-4.1 --username=anonymous --password="" Yes it is a little bit clumsy. I suggest that the SVN development team address this issue.
Re: Infamous "Item is not readable" for svn log
On Feb 26, 2010, at 2:03 PM, Bob Archer wrote: > I think setting up a guest username with no password is the easiest way to go. That's how we're doing it on our repository. It's a little clumsy, but workable for our user population. > Baring that setting up apache for anon requests and svn for authenticated. That would also work. In our case we didn't really want the added complexity of Apache -- plus I was worried about user confusion. I already have a fair number of people who get http: and svn: mixed up from time to time. Having http: work in some situations but not others would just add to their perplexity. -- David Brodbeck System Administrator, Linguistics University of Washington
RE: Infamous "Item is not readable" for svn log
> > Did you attempt to pass your user credentials with the svn log command? > > Yes. There is a discussion regarding that here: > > http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&viewType=b > rowseAll&dsMessageId=173879 I think setting up a guest username with no password is the easiest way to go. Baring that setting up apache for anon requests and svn for authenticated. Seems like this shouldn't be so hard. Luckily we haven't needed path authorization yet. BOb
Re: Infamous "Item is not readable" for svn log
> Did you attempt to pass your user credentials with the svn log command? Yes. There is a discussion regarding that here: http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&viewType=browseAll&dsMessageId=173879
RE: Infamous "Item is not readable" for svn log
> I've found quite a few hits on Google regarding this subject, but I > have not found any elegant solutions to this problem. > > I'm running SVN 1.6.9 (r901367) on FreeBSD (built from ports). I have > the svnserve daemon running. I'm trying to have some areas of my > repository be public (requiring no auth) and others be private > (requiring auth even for read access). So, lines in my svnserve.conf: > > [general] > anon-access = read > auth-access = write > password-db = passwd > authz-db = authz > realm = Rambetter's Code Repository > [sasl] > use-sasl = false > > > Lines from passwd: > > [users] > maj = fakepass > rambetter = fakepass > > > Lines from authz: > > [aliases] > [groups] > [/] > rambetter = rw > * = r > [/repos/urt-playerdb] > rambetter = rw > * = > [/repos/ioUrT-server-4.1-supersecret] > maj = rw > * = > [/repos/jblockout] > rambetter = rw > * = > [/repos/ioquake3-server-1.36-rambetter] > rambetter = rw > * = > [/repos/ioUrT-server-4.1-rambetter] > rambetter = rw > * = > > > I cannot perform an "svn log" from the paths above that have the "* =" > (to restrict read access to the public). The error message is "svn: > Item is not readable" when I perform and "svn log" on these restricted > directories. > > I know this is a common problem, but is there an elegant way to to > have both publicly readable and protected sections in the same > repository? I have done one thing in the past, which is to create a > user called "anonymous" with the empty password, and I tell the public > that to check out they type this: > > svn checkout svn://daffy.nerius.com/repos/ioUrT-server-4.1 > --username="anonymous" --password="" > > ... but this approach seems to be very clumsy. > > Another solution that comes to mind is to start a whole new repository > with a separate svnserve daemon. How would I move over an entire > directory, all history included, if I were to do this? > > Any other solutions? Did you attempt to pass your user credentials with the svn log command? BOb
Infamous "Item is not readable" for svn log
I've found quite a few hits on Google regarding this subject, but I have not found any elegant solutions to this problem. I'm running SVN 1.6.9 (r901367) on FreeBSD (built from ports). I have the svnserve daemon running. I'm trying to have some areas of my repository be public (requiring no auth) and others be private (requiring auth even for read access). So, lines in my svnserve.conf: [general] anon-access = read auth-access = write password-db = passwd authz-db = authz realm = Rambetter's Code Repository [sasl] use-sasl = false Lines from passwd: [users] maj = fakepass rambetter = fakepass Lines from authz: [aliases] [groups] [/] rambetter = rw * = r [/repos/urt-playerdb] rambetter = rw * = [/repos/ioUrT-server-4.1-supersecret] maj = rw * = [/repos/jblockout] rambetter = rw * = [/repos/ioquake3-server-1.36-rambetter] rambetter = rw * = [/repos/ioUrT-server-4.1-rambetter] rambetter = rw * = I cannot perform an "svn log" from the paths above that have the "* =" (to restrict read access to the public). The error message is "svn: Item is not readable" when I perform and "svn log" on these restricted directories. I know this is a common problem, but is there an elegant way to to have both publicly readable and protected sections in the same repository? I have done one thing in the past, which is to create a user called "anonymous" with the empty password, and I tell the public that to check out they type this: svn checkout svn://daffy.nerius.com/repos/ioUrT-server-4.1 --username="anonymous" --password="" ... but this approach seems to be very clumsy. Another solution that comes to mind is to start a whole new repository with a separate svnserve daemon. How would I move over an entire directory, all history included, if I were to do this? Any other solutions?
Re: Using memcached on Windows with SVN 1.6
Thanks for the responses so far. > Not to discourage you from trying, but the others that have done the same did not see any tangible benefits. Most of these users were already using pretty fast disk systems for their repositories, so perhaps if yours are on a single spindle or something and you have a lot of RAM for the cache you might see different. The tests that I've seen seem to have been done using some serious hardware. My situation is much more modest with a SVN repository on a disk shared by a bunch of other processes. They were never specifically compiled with our without memcached. The binaries are including the latest (as of a month ago) version of httpd and apr and using the standard Apache build process that it provides. If that builds memcache support on Windows then they include them. If you have to retrieve some special package or use special compile options then it does not and never has. I should have added that we provide the source code and build scripts that go into each release alongside the download. So feel free to download the source zip and look at the scripts etc. I have downloaded the source for the Collabnet Subversion server. Comments at this website: http://github.com/apache/apr-util say that: To give a brief overview, the primary core subsystems of APR-util 1.3 include the following: ... MemCache interface ... Which would make me believe that if you are using their standard build for APR-util that it would have memcache support rolled in. A search within the libaprutil-1.dll (version 1.3.9) that comes within the collab install does show up references to the following functions: apr_memcache_add apr_memcache_add_multget_key apr_memcache_add_server Again this feels like it has had support for it compiled in. I can't find anything specific that says you must do blah to compile support for it on windows. Thanks, Matthew On Fri, Feb 26, 2010 at 5:58 PM, Mark Phippard wrote: > On Fri, Feb 26, 2010 at 7:57 AM, Mark Phippard wrote: > > On Fri, Feb 26, 2010 at 7:54 AM, Stefan Sperling wrote: > >> On Fri, Feb 26, 2010 at 05:44:38PM +0200, Matthew Beets wrote: > >>> Now when I try to checkout my empty test repository ( using "svn > checkout > >>> svn://localhost/test C:\svntestcheckout" ) I get the message: > >>> > >>> svn: apr memcache library not available > >> > >> Sounds like the APR library shiipping with the collab.net svn binaries > >> has not been compiled with support for memcached. > >> > >> They certainly used to, but maybe this has changed? > >> See http://svn.haxx.se/users/archive-2009-06/0676.shtml > > > > They were never specifically compiled with our without memcached. The > > binaries are including the latest (as of a month ago) version of httpd > > and apr and using the standard Apache build process that it provides. > > If that builds memcache support on Windows then they include them. If > > you have to retrieve some special package or use special compile > > options then it does not and never has. > > I should have added that we provide the source code and build scripts > that go into each release alongside the download. So feel free to > download the source zip and look at the scripts etc. > > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/ >
Re: Empty logentry block in 'svn log --xml'
On Fri, Feb 26, 2010 at 12:56:32PM +0530, John Christopher Turner wrote: > Command being executed: > svn --username *** --password *** log --non-interactive --xml -v > --limit 1 svn://hostname/url/path > > Response: > > > > > > > > We made the assumption that there would always be content in that > section, but that was clearly invalid. Any ideas on what the cases are > where this could possibly happen? This may be a dumb question but is there a commit message for revision 3861? AFAIK svn has no problem with empty commit messages. tyler
assertion failure, tree_conflicts.c
Tortoise svn asked me to report a serious problem, so ... In file 'D:\Development\SVN\Releases\TortoiseSVN-1.6.6\ext\subversion\subversion\libsvn_wc\tree_conflicts.c' Line 570: assertion failed (strcmp(dir_path, snv_path_dirname(victim_path, pool)) == 0) I had, perhaps a week ago, used tortoiseSVN Switch to switch to a tag and had just switched back to the trunk and was trying to get the working copy into a sensible state (using update and revert)-the switch back seemed to have left things in a strange state with changes from the trunk which I hadn't expected. Regards, Tim Wilkins
Could not resolve hostname error
I get the following error when attempting to do the following commands svn update, log, list, blame etc. svn diff and svn info works fine. http://xxx01/comm/JavaService/trunk/: Could not resolve hostname `http://xxx01/comm': The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. The same issue occurs on various clients on my computer, but I am able to access via the web. This only occurs on my laptop and only started occurring this week after using subversion for several months. This does not occur when using another remote desktop. Any help is appreciated. Thanks - This e-mail message may contain privileged and/or confidential information, and is intended to be received only by persons entitled to receive such information. If you have received this e-mail in error, please notify the sender immediately. Please delete it and all attachments from any servers, hard drives or any other media. Other use of this e-mail by you is strictly prohibited. All e-mails and attachments sent and received are subject to monitoring, reading and archival by Monsanto, including its subsidiaries. The recipient of this e-mail is solely responsible for checking for the presence of "Viruses" or other "Malware". Monsanto, along with its subsidiaries, accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment. -
Re: Using memcached on Windows with SVN 1.6
On Fri, Feb 26, 2010 at 7:57 AM, Mark Phippard wrote: > On Fri, Feb 26, 2010 at 7:54 AM, Stefan Sperling wrote: >> On Fri, Feb 26, 2010 at 05:44:38PM +0200, Matthew Beets wrote: >>> Now when I try to checkout my empty test repository ( using "svn checkout >>> svn://localhost/test C:\svntestcheckout" ) I get the message: >>> >>> svn: apr memcache library not available >> >> Sounds like the APR library shiipping with the collab.net svn binaries >> has not been compiled with support for memcached. >> >> They certainly used to, but maybe this has changed? >> See http://svn.haxx.se/users/archive-2009-06/0676.shtml > > They were never specifically compiled with our without memcached. The > binaries are including the latest (as of a month ago) version of httpd > and apr and using the standard Apache build process that it provides. > If that builds memcache support on Windows then they include them. If > you have to retrieve some special package or use special compile > options then it does not and never has. I should have added that we provide the source code and build scripts that go into each release alongside the download. So feel free to download the source zip and look at the scripts etc. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Using memcached on Windows with SVN 1.6
On Fri, Feb 26, 2010 at 7:54 AM, Stefan Sperling wrote: > On Fri, Feb 26, 2010 at 05:44:38PM +0200, Matthew Beets wrote: >> Now when I try to checkout my empty test repository ( using "svn checkout >> svn://localhost/test C:\svntestcheckout" ) I get the message: >> >> svn: apr memcache library not available > > Sounds like the APR library shiipping with the collab.net svn binaries > has not been compiled with support for memcached. > > They certainly used to, but maybe this has changed? > See http://svn.haxx.se/users/archive-2009-06/0676.shtml They were never specifically compiled with our without memcached. The binaries are including the latest (as of a month ago) version of httpd and apr and using the standard Apache build process that it provides. If that builds memcache support on Windows then they include them. If you have to retrieve some special package or use special compile options then it does not and never has. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Using memcached on Windows with SVN 1.6
On Fri, Feb 26, 2010 at 7:44 AM, Matthew Beets wrote: > I am experimenting with some of the new options in 1.6 and I'm trying to > investigate any benefits using memcached may provide. Not to discourage you from trying, but the others that have done the same did not see any tangible benefits. Most of these users were already using pretty fast disk systems for their repositories, so perhaps if yours are on a single spindle or something and you have a lot of RAM for the cache you might see different. > I am trying to get this running on Windows XP 32 bit with CollabNet > Subversion Server 1.6.9 (http://www.collab.net/downloads/subversion/) > and NorthScale Windows port of memcached 1.4.4 > (http://labs.northscale.com/memcached-packages/) > I am using both the CollabNet svn command line client and TortoiseSVN 1.6.6 > I install Collabnet server, start the subversion windows service and create > a test repository using svnadmin at the command prompt. > I run the memcached.exe that comes in the NorthScale package (no command > line options. It is supposed to be listening on port 11211 by default.) > I navigate to the fsfs.conf file for my test repository and uncomment the > line "first-server = 127.0.0.1:11211" > Now when I try to checkout my empty test repository ( using "svn checkout > svn://localhost/test C:\svntestcheckout" ) I get the message: > svn: apr memcache library not available It sounds like when the CollabNet httpd binaries are compiled there is something special that has to be done to compile in memcache support. It is also possible the httpd/apr just does not support this on Windows. The latest CollabNet binaries include httpd 2.2.14. You could try downloading that version of httpd from Apache and see if it is compiled differently. Just use the mod_dav_svn that CollabNet provides with those binaries. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Using memcached on Windows with SVN 1.6
On Fri, Feb 26, 2010 at 05:44:38PM +0200, Matthew Beets wrote: > Now when I try to checkout my empty test repository ( using "svn checkout > svn://localhost/test C:\svntestcheckout" ) I get the message: > > svn: apr memcache library not available Sounds like the APR library shiipping with the collab.net svn binaries has not been compiled with support for memcached. They certainly used to, but maybe this has changed? See http://svn.haxx.se/users/archive-2009-06/0676.shtml By the way, typing "memcached" into the search box at http://svn.haxx.se/ turns up lots of information, including people reporting performance measurements. > I'm not sure what to do at this point. Am I missing a step? Is there > something extra that I need to make this work on Windows? Find binaries built with APR with memcached support. You may need to build your own. Stefan
Using memcached on Windows with SVN 1.6
Hello, I am experimenting with some of the new options in 1.6 and I'm trying to investigate any benefits using memcached may provide. I am trying to get this running on Windows XP 32 bit with CollabNet Subversion Server 1.6.9 (http://www.collab.net/downloads/subversion/) and NorthScale Windows port of memcached 1.4.4 ( http://labs.northscale.com/memcached-packages/) I am using both the CollabNet svn command line client and TortoiseSVN 1.6.6 I install Collabnet server, start the subversion windows service and create a test repository using svnadmin at the command prompt. I run the memcached.exe that comes in the NorthScale package (no command line options. It is supposed to be listening on port 11211 by default.) I navigate to the fsfs.conf file for my test repository and uncomment the line "first-server = 127.0.0.1:11211" Now when I try to checkout my empty test repository ( using "svn checkout svn://localhost/test C:\svntestcheckout" ) I get the message: svn: apr memcache library not available If I comment the line "first-server = 127.0.0.1:11211" in the fsfs.conf file back out, then I can checkout the repository. I'm not sure what to do at this point. Am I missing a step? Is there something extra that I need to make this work on Windows? Any help is appreciated! Thank you, Matthew
Re: Tree conflict - svn status cannot show?
On Fri, Feb 26, 2010 at 12:05:52AM +, Barry Scott wrote: j > On 25 Feb 2010, at 23:18, Stefan Sperling wrote: > > > On Thu, Feb 25, 2010 at 10:30:18PM +, Barry Scott wrote: > >> I starting to see failures to commit because of tree conflicts. > >> > >> svn status does not seem to show tree conflicts. > > > > It sure does. See examples here: > > http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html > > We notice tree conflict after folder moves. Not seen one for a file move yet. > This example only about file issues not folder issues. > > > > >> Did I miss the way to find the tree conflicts? > > > > Not sure. What commands are you running and what output are you seeing? > > svn st -q > > and the output is blank. > > (I ran svn st -q after pysvn workbench failed to show anything problems.) What version of svn? Below 1.6.3? If so, this could be http://subversion.tigris.org/issues/show_bug.cgi?id=3382 which was fixed in 1.6.3. If this is not the problem, please try to come up with a script that others can use to reproduce the problem, starting from an empty repository. Stefan
Re: AW: Corrupted FSFS commit
Kutter, Martin wrote on Fri, 26 Feb 2010 at 10:29 +0100: > The reported numbers are unstable, and flip between positive and > negative values. They don't have any reason to differ across runs, do they? So, what's next? Uninitialized memory? Valgrind? (and how to make it play nicely with pools, I don't rememeber) > First, I think that the error should have been reported > on commit, not on checkout. You can run verify/dump automatically on every commit to help catch these errors. > I'm afraid the commit just got corrupted somehow - is there a way to > remove/replace it in the repository? If 1.6.5 dumps without aborting, I suppose you could dump/load with svndumpfilter to remove the added path. Or you could configure authz rules to prevent you from seeing the 'problematic' added path, and then run svnsync as usual (it would ignore paths that aren't authz-readable for it). Daniel
AW: Corrupted FSFS commit
> Daniel Shahaf wrote: > Kutter, Martin wrote on Thu, 25 Feb 2010 at 13:29 +0100: > > I got a strange error in one of our subversion > > repositories: On checking > > out a file from revision 3865 on, svn reports "Svndiff > > contains a too-large window". > > > This is the error message added in 1.6.4 as part of the security fix > > then. You may want to try a 1.6.3 server (the last release > *without* > > the security fix). A subversion 1.6.3 svnadmin yields: @> ./svnadmin-1.6.3 dump /repo -r 3865 > 3865.svndump Aborted @> The resulting (aborted) dump file is 71072278 bytes, the one from a 1.6.5 svnadmin is 71072237 bytes long Martin
AW: Corrupted FSFS commit
Daniel Shahaf wrote: > Kutter, Martin wrote on Thu, 25 Feb 2010 at 13:29 +0100: > > I got a strange error in one of our subversion > > repositories: On checking > > out a file from revision 3865 on, svn reports "Svndiff > > contains a too-large window". > > This is the error message added in 1.6.4 as part of the security fix > then. You may want to try a 1.6.3 server (the last release *without* > the security fix). This is what I found on the web on this message. However, the commit was performed using client and server >= 1.6.4, and a modified svnadmin (reporting the numbers checked along with the error message) clearly shows some kind of overflow: The reported numbers are unstable, and flip between positive and negative values. Testing with 1.6.3, which has the security error, seems not very appealing: First, I think that the error should have been reported on commit, not on checkout. Moreover, it's quite unlikely that 1.6.3 will be able to handle the revision file correctly - it's much more likely that the revision will trigger the security error. I'm afraid the commit just got corrupted somehow - is there a way to remove/replace it in the repository? Regards, Martin
How to recover from "Found malformed header in revision file"?
How to recover from "Found malformed header in revision file"? > svn commit myfile Sendingmyfile Transmitting file data .svn: Commit failed (details follow): svn: Corrupt node-revision '0-484.0-123.r993/92' svn: Found malformed header in revision file So I tried create a dump file: > svnadmin dump /site/svn/ > dumpsvn * Dumped revision 0. ... * Dumped revision 987. svnadmin: Corrupt representation '988 0 8767 8749 17d4a0cc3e480c0c64dd8107a1854b7f' svnadmin: Malformed representation header So it started a long long time ago... :( > svn --version svn, version 1.5.1 (r32289) compiled Aug 7 2009, 01:15:13 This the version of svn from ubuntu for whatever version is running on that machine. If a dump of the repo doesn't work, what next???
