This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Copies of the GCC repository
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: Daniel Jacobowitz <drow at false dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 22 Nov 2005 11:30:08 -0500
- Subject: Re: Copies of the GCC repository
- References: <1130527765.17718.24.camel@linux.site> <20051108011747.GA1820@nevyn.them.org> <m3ek58br9r.fsf@uniton.integrable-solutions.net>
On Tue, 2005-11-22 at 17:07 +0100, Gabriel Dos Reis wrote:
> Daniel Jacobowitz <drow@false.org> 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
Switch the url to be svn+ssh, and your problem will go away.
> (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.
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.
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.
push is actually implemented in terms of smerge, so i would not be
surprised to find out that you were hitting this case.
--Dan