I installed Gentoo + Subversion to provide the service through svnserve.
But I use the TSVN client side to link the SVN service demonstrated
frequently: Cannot connect, initiative rejection, prompts and so on
force closure.
I have closed the local firewall, the question as before.
I am a
Hello,
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: Working copy is too old.
Should I downgrade subversion or just waiting till the particular
layman repositorys' format will be upgraded?
The problem is with your working copy, not with the repository.
Subversion
Dear All,
Yesterday my subversion has been upgraded because I have an ~amd64
system. This morning when I wanted to sync my layman repositorys I got
this error message:
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: Working copy is too old.
Should I downgrade subversion
I'm using layman to pull in the je_fro overlay and I'm getting this:
Unpacking source...
* subversion switch start --
* old repository: http://svn.madwifi.org/madwifi/[EMAIL PROTECTED]
* new repository: http://svn.madwifi-project.org/madwifi/trunk
svn:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Grant wrote:
I'm using layman to pull in the je_fro overlay and I'm getting this:
Unpacking source...
* subversion switch start --
* old repository: http://svn.madwifi.org/madwifi/[EMAIL PROTECTED]
* new repository:
I'm using layman to pull in the je_fro overlay and I'm getting this:
Unpacking source...
* subversion switch start --
* old repository: http://svn.madwifi.org/madwifi/[EMAIL PROTECTED]
* new repository: http://svn.madwifi-project.org/madwifi/trunk
svn:
Suddenly (at least I don't know since when it doesn't work) I get this
error whenever I use svn:
svn: Failed to find label 'NULL' for URL '/svnroot/arcon/trunk/overlay'
svn: Failed to find label 'NULL' for URL '/svnroot/arcon/trunk/overlay'
Subversion (1.5.4) is build with
USE:-apache2
hmm, probably
a) broken ebuild (missing bdb dep)
b) broken ./configure script (which can't find existing bdb)
cu
--
-
Enrico Weigelt== metux IT service - http://www.metux.de/
For now I masked the version of
On Wed, 11 Jun 2008 14:17:44 +0200
Dirk Uys [EMAIL PROTECTED] wrote:
hmm, probably
a) broken ebuild (missing bdb dep)
b) broken ./configure script (which can't find existing bdb)
cu
--
-
Enrico Weigelt==
On Wed, Jun 11, 2008 at 3:09 PM, Florian Philipp
[EMAIL PROTECTED] wrote:
On Wed, 11 Jun 2008 14:17:44 +0200
Dirk Uys [EMAIL PROTECTED] wrote:
For now I masked the version of subversion giving the problems, I only
occasionally use subversion on that machine. I would however like to
* Dirk Uys [EMAIL PROTECTED] wrote:
Hi everyone.
When I emerge subversion, i get the following error:
snip
checking for availability of Berkeley DB... no
configure: error: Berkeley DB 4.0.14 wasn't found.
hmm, probably
a) broken ebuild (missing bdb dep)
b) broken ./configure script
On Sun, 8 Jun 2008 12:52:03 +0200
Dirk Uys [EMAIL PROTECTED] wrote:
Hi everyone.
When I emerge subversion, i get the following error:
snip
checking for availability of Berkeley DB... no
configure: error: Berkeley DB 4.0.14 wasn't found.
!!! Please attach the following file when
Hi everyone.
When I emerge subversion, i get the following error:
snip
checking for availability of Berkeley DB... no
configure: error: Berkeley DB 4.0.14 wasn't found.
!!! Please attach the following file when seeking support:
!!!
On Monday 30 April 2007, Johannes Skov Frandsen wrote:
Hi
I have currently installed version 1.3.2-r3 of subversion, but I have
installed th latest version of subclipse (svn plugin for the eclipse
platform), and now I can't use svn from the shell.
I get
svn: This client is too old to work
Nistor Andrei wrote:
On Monday 30 April 2007, Johannes Skov Frandsen wrote:
Hi
I have currently installed version 1.3.2-r3 of subversion, but I have
installed th latest version of subclipse (svn plugin for the eclipse
platform), and now I can't use svn from the shell.
I get
svn: This
on Sunday 02/11/2007 Bo Ørsted Andresen([EMAIL PROTECTED]) wrote
On Saturday 10 February 2007 15:28:14 John covici wrote:
Hi. I am having a strange subversion problem. I think it stems from
the fact that I boot into two different systems, one has subversion
1.4.0and the gentoo system
On Sunday 11 February 2007 11:00:15 John covici wrote:
But would I not get that version when I do
emerge -S subversion
that search yields only the 1.3.2, so I thought there was no later
one.
I did a find /usr/portage -name '*subversion*' and sure enough there
a 1.4.2 ebuild, but the search
Hi. I am having a strange subversion problem. I think it stems from
the fact that I boot into two different systems, one has subversion
1.4.0and the gentoo system has 1.3.2 and when the 1.3.2 client touches
something checked out by the 1.4.0 version, it complains -- does seem
to work. However
On Saturday 10 February 2007 15:28:14 John covici wrote:
Hi. I am having a strange subversion problem. I think it stems from
the fact that I boot into two different systems, one has subversion
1.4.0and the gentoo system has 1.3.2 and when the 1.3.2 client touches
something checked out by
On Friday 10 November 2006 05:09, Daevid Vincent wrote:
The problem I'm running into is that I use the TortoiseSVN 1.4.x on my
winXP box which is mounting via samba my SVN checkout on the linux box.
That has 1.3.1 on it. When I try to do any svn commands from the command
line on linux, it
I see on the tigris site that 1.4.2 is the latest version, but portage shows
1.40 as the latest ebuild (which is also ~x86).
http://packages.gentoo.org/search/?sstring=subversion
The problem I'm running into is that I use the TortoiseSVN 1.4.x on my winXP
box which is mounting via samba my SVN
Anybody have any idea when subversion 1.3 will available as an ebuild?
--
gentoo-user@gentoo.org mailing list
On 2006-03-15 00:47, David Corbin uttered these thoughts:
Anybody have any idea when subversion 1.3 will available as an ebuild?
It is... Marked testing on most architectures it seems.
If you want it, read man portage and look for package.keywords
Regards,
Patrick Börjesson
--
/ () The
Holly Bostick wrote:
The thing is Portage doesn't *remember* ACCEPT_KEYWORDS, beyond the
original compile in which it is used. So if you use it, and keep the
package, as soon as you do an emerge -u world, Portage will try to
downgrade the package to the last stable version, which is the
Steve [Gentoo] wrote:
The only way in which I'm not yet as convinced as you are is with
respect to dependencies. I'm comfortable with the idea that I browse
the bugs to verify that none of the issues affect my install directly -
then to accept an unstable version of a specific package...
I'd have thought lots of people in the gentoo crowd would have been
eagerly awaiting subversion 1.2.x with its substantial new reserved
checkout - but nothing seems to have moved forward.
Portage (by default) still gives me version 1.1.3... but version 1.2 has
been available for a couple of
Steve [Gentoo] wrote:
I'd have thought lots of people in the gentoo crowd would have been
eagerly awaiting subversion 1.2.x with its substantial new reserved
checkout - but nothing seems to have moved forward.
Portage (by default) still gives me version 1.1.3... but version 1.2
has been
Steve [Gentoo] wrote:
I'd have thought lots of people in the gentoo crowd would have been
eagerly awaiting subversion 1.2.x with its substantial new reserved
checkout - but nothing seems to have moved forward.
you must have missed this link from the gentoo homepage (on the left):
Marco Matthies wrote:
Gentoo leaves packages in unstable for a default period of time to make sure
they work allright. If you want the newest version of a package, you must tell
portage to do so by putting the appropriate stuff (subversion and it's
dependencies) in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve [Gentoo] wrote:
Hmmm - that all sounds sane, but what is this default period of time?
What criteria must be met in order for a masked package (and
specifically for Subversion) to become unmasked?
At least a month and there can't be any
Steve [Gentoo] wrote:
Hmmm - that all sounds sane, but what is this default period of time?
What criteria must be met in order for a masked package (and
specifically for Subversion) to become unmasked?
I *think* it is something along the lines of 30 days without a bug,
not 100% sure though.
All of my subversion repositories are broken for the second time in
less than a month. I haven't even used them in about a week or more.
The machine hasn't crashed, nothing I can think of that would cause a
problem has occured.
svn update
svn: Unable to open an ra_local session to URL
svn:
32 matches
Mail list logo