Daniel Berlin <[EMAIL PROTECTED]> writes: | On Tue, 2005-11-22 at 17:07 +0100, Gabriel Dos Reis wrote: | > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: | > | > [...] | > | > | There's a lot to be learned (for me at least) about using svk. At some | > | point I will update the wiki with useful bits, but I don't have many | > | just yet. For instance, two open questions while I was writing this: | > | | > | - how to make svk refuse commits to the mirrored portion instead of | > | wanting to push them upstream | > | - how to make svk access depots remotely | > | | > | I'm sure they're both possible, I just don't know how yet :-) | > | > Well, since I do not have an imperial machine equipped lot of gigs on | > the harddrive, I took the SVK suggestion very seriously. | > | > At the moment, my attempts to commit patches (based on SVK) have met | > failures and generated lot of frustration. | > | > I have a patchlet to cp/error.c I wanted to commit; so I followed the | > instructions on the Wiki. My local tree is uptodate with respect to | > upstream; I launched "svk push --lump". After 5 minutes waiting, I | > pressed ^C. Then I tried "svk commit"; it prompted me with my | > favorite editor, I entered the commit-log, saved it and exited the | > editor. At that time, I was greated with: | > | > Merging back to mirror source svn://gcc.gnu.org/svn/gcc. | > Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/vendor_perl/5.8.6/i586-linux-thread-multi/SVN/Core.pm line 576. | > Authorization failed: at /usr/lib/perl5/vendor_perl/5.8.6/SVK/Command.pm line 152 | | Authorization failed because you are trying to commit to the readonly | repository, note the url is svn://gcc.gnu.org/svn/gcc
Doh. I'm pretty sure I would have spent less time if I got a diagnostic saying 'write access missing' (or something like that) instead of use of unitialized value and authorization failure. | | Switch the url to be svn+ssh, and your problem will go away. Thanks for the suggestion! It solved my commit problem. I followed the instructions on the wiki... I'll update the wiki for those with write access who did not want to start from scratch that after initialization of the depotmap, they need to issue svk mirror --relocate //gcc svn+ssh://gcc.gnu.org/svn/gcc | > (2) Is it normal that "svk push" takes more than 5 minutes to complete? | > If so, that does not match the speed argument I've seen for the | > move to SVN. | | I've never said anything about the speed of SVK, because I don't use | SVK. Others have. | | You are using quite an old version of SVK, because SVK changes very | rapidly. | | I don't know whether SVK push is supposed to take 5 minutes, but i would | not be surprised to find it true of version 0.29. my system says indeed: merlin[12:08]% rpm -q svk svk-0.29-7 | SVK works at the speed the repository works at. | | There are some significant performance issues with the repository that | were solved in SVN 1.3 and SVK 1.05 by use of a new API we provide in | Subversion. | | http://svk.elixus.org/?ReleaseNotes105 | | "Make use of the new svn API (fs_closest_copy) when available. This | boosts performance for smerge, switch and info." | | Prior to that API, some operations on the repository took minutes, and | now take seconds, because it would have to look at every file to find | where copies occurred. This is normally a server-side only change, and | our server runs 1.3, and thus, takes advantage of this on the SVN side, | with no client modifications. Thanks for the suggestion. I'll update to newer SVK once I get the more pressing issues out of my way. | However, SVK users are effectively running local servers (in terms of | API used), and thus, would also have to run 1.3 and the approriate | version of SVK to take advantage of these improvements. I'm running the version of SVN made available on the wiki page. | push is actually implemented in terms of smerge, so i would not be | surprised to find out that you were hitting this case. -- Gaby
