Return-Path: 
 <users-return-21720-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org>
X-Original-To: apmail-subversion-users-archive@minotaur.apache.org
Delivered-To: apmail-subversion-users-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 27E6C1176C
	for <apmail-subversion-users-archive@minotaur.apache.org>;
 Mon,  7 Jul 2014 12:48:48 +0000 (UTC)
Received: (qmail 74218 invoked by uid 500); 7 Jul 2014 12:48:47 -0000
Delivered-To: apmail-subversion-users-archive@subversion.apache.org
Received: (qmail 74187 invoked by uid 500); 7 Jul 2014 12:48:47 -0000
Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@subversion.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@subversion.apache.org>
List-Post: <mailto:users@subversion.apache.org>
List-Id: <users.subversion.apache.org>
Delivered-To: mailing list users@subversion.apache.org
Received: (qmail 74177 invoked by uid 99); 7 Jul 2014 12:48:47 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Jul 2014 12:48:47 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of brane@wandisco.com designates
 74.125.82.52 as permitted sender)
Received: from [74.125.82.52] (HELO mail-wg0-f52.google.com) (74.125.82.52)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Jul 2014 12:48:44 +0000
Received: by mail-wg0-f52.google.com with SMTP id b13so4249201wgh.23
        for <users@subversion.apache.org>;
 Mon, 07 Jul 2014 05:48:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=wandisco.com; s=gapps;
        h=message-id:date:from:organization:user-agent:mime-version:to:cc
         :subject:references:in-reply-to:content-type;
        bh=IsNiywmg8vzJ8Pfs6W+BwLtGN50bgNiXBQaDAyB3kGQ=;
        b=FXGz+bTUuEPd4vjNm/xDFpZ7umK6etpqxBqKiGIdIgDYYYSQBV8Z+DdFvd5bgrlUIY
         cPDqm4AsSMfdEyllzcguRIVXnZxCfVahpDVYX0MYFYqPk2nFCrx8p5RgdLFCJ8Nr9e6I
         peKESPbUbRAD4IE0/90KzMOZiANMnRgIhYJDY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:message-id:date:from:organization:user-agent
         :mime-version:to:cc:subject:references:in-reply-to:content-type;
        bh=IsNiywmg8vzJ8Pfs6W+BwLtGN50bgNiXBQaDAyB3kGQ=;
        b=ST+TXnVMXPIKdVOI6RI4MLPS4O9QGOCgFtJRTF6Sfg6MDQu3BhoGADLEe6l6Qn5mv5
         dF3s3Zn4sz1sh2sKox9xIxomka3sdgN1vNm0Ugu52InDZgQKBd5wGBaGkkjbL0/beGP5
         /aLtq2i48GZIVuW6tYEQtuIYRa2tLJb4Getwa4DI3ujYQm2csuc9pOM10DhX5GroReav
         mT9dkUTt46mz7ma5i8nkSsVERQ+/B97YD5gi9Rl7A/GW/FqmpyWcC3johK5KBnJtcldp
         UPmISihSZC4OthbNDND160FtTGkSAEI5OW3tYA7QeYRAMQeg9iGNDbLVu/QZNBWtuCN5
         Bd4Q==
X-Gm-Message-State: 
 ALoCoQk2LdCICCHDxpo9Fdg8FEzXrbIgvRGpd0/UT103qLWBwzZzc+WNk3qt0ZK3J9gOyE0t/CN2
X-Received: by 10.195.11.34 with SMTP id ef2mr3107626wjd.123.1404737295966;
        Mon, 07 Jul 2014 05:48:15 -0700 (PDT)
Received: from zulu.local (cpe-46-164-37-44.dynamic.amis.net. [46.164.37.44])
        by mx.google.com with ESMTPSA id
 ch5sm89256475wjb.18.2014.07.07.05.48.14
        for <multiple recipients>
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Mon, 07 Jul 2014 05:48:15 -0700 (PDT)
Received: from zulu.local (localhost [IPv6:::1])
	by zulu.local (Postfix) with ESMTP id 5FDB3B37DC22;
	Mon,  7 Jul 2014 14:48:13 +0200 (CEST)
Message-ID: <53BA970D.5070602@wandisco.com>
Date: Mon, 07 Jul 2014 14:48:13 +0200
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@wandisco.com>
Organization: WANdisco
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Nico Kadel-Garcia <nkadel@gmail.com>
CC: Subversion <users@subversion.apache.org>
Subject: Re: Subversion 1.8.9 repository access issue [Urgent]
References: 
 <CALL-kDdukyrLJGJcekGRG_NYz-HH=ewEHKzNTAH_=Ciy55cu1A@mail.gmail.com>
	<53B93485.4000404@gmx.de>	<53B9B873.2090603@wandisco.com>
	<53B9C57E.5030901@gmx.de>	<53BA4B06.4000504@wandisco.com>
	<CAOCN9rxOLHd8N83Cn4c1hGLEUH3jfsXvG-jmNjFe=1xEYjUqVA@mail.gmail.com>
	<53BA8119.1040601@wandisco.com>
 <CAOCN9rwNr2kpmNU6h-cL5g50F2WrigMHdx=Vckpb7LEFGYPn1g@mail.gmail.com>
In-Reply-To: 
 <CAOCN9rwNr2kpmNU6h-cL5g50F2WrigMHdx=Vckpb7LEFGYPn1g@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------060400010905080608010000"
X-Virus-Checked: Checked by ClamAV on apache.org

This is a multi-part message in MIME format.
--------------060400010905080608010000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 07.07.2014 14:11, Nico Kadel-Garcia wrote:
> On Mon, Jul 7, 2014 at 7:14 AM, Branko Čibej <brane@wandisco.com> wrote:
>> On 07.07.2014 12:48, Nico Kadel-Garcia wrote:
>>> On Mon, Jul 7, 2014 at 3:23 AM, Branko Čibej <brane@wandisco.com> wrote:
>>>> On 06.07.2014 23:54, Andreas Stieger wrote:
>>>> Berkeley DB databases can always be upgraded from older BDB versions with
>>>> db_upgrade, if the BDB version on the new server is incompatible with the
>>>> one on the old server. Nothing else should really matter.
>>>>
>>> This is not necessarily reliable. I've encountered at least 4 BDB
>>> environments that worked as they were, but for which 'db_upgrade' was
>>> impossible. It even paid serious consulting rates while I backported a
>>> bunch of CentOS tools to work with an old BDB environment that someone
>>> had hand built and not written a usable 'export' function for.
>>>
>>> I have never found BDB to be stable or reliable enough for production use.
>> That's an answer to a different question. :)
> Clipping some material: no, it's not a different question. BDB
> databases *cannot* always be upgraded with db_upgrade, I thought I was
> clear about that.

The question that started this thread was why a BDB database could not
be opened. The answer is, because the BDB back-end was not built. We
don't even know that the old and new BDB versions are different.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

--------------060400010905080608010000
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 07.07.2014 14:11, Nico Kadel-Garcia
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAOCN9rwNr2kpmNU6h-cL5g50F2WrigMHdx=Vckpb7LEFGYPn1g@mail.gmail.com"
      type="cite">
      <pre wrap="">On Mon, Jul 7, 2014 at 7:14 AM, Branko Čibej <a class="moz-txt-link-rfc2396E" href="mailto:brane@wandisco.com">&lt;brane@wandisco.com&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 07.07.2014 12:48, Nico Kadel-Garcia wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">On Mon, Jul 7, 2014 at 3:23 AM, Branko Čibej <a class="moz-txt-link-rfc2396E" href="mailto:brane@wandisco.com">&lt;brane@wandisco.com&gt;</a> wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">On 06.07.2014 23:54, Andreas Stieger wrote:
</pre>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">Berkeley DB databases can always be upgraded from older BDB versions with
db_upgrade, if the BDB version on the new server is incompatible with the
one on the old server. Nothing else should really matter.

</pre>
          </blockquote>
          <pre wrap="">This is not necessarily reliable. I've encountered at least 4 BDB
environments that worked as they were, but for which 'db_upgrade' was
impossible. It even paid serious consulting rates while I backported a
bunch of CentOS tools to work with an old BDB environment that someone
had hand built and not written a usable 'export' function for.

I have never found BDB to be stable or reliable enough for production use.
</pre>
        </blockquote>
        <pre wrap="">
That's an answer to a different question. :)
</pre>
      </blockquote>
      <pre wrap="">
Clipping some material: no, it's not a different question. BDB
databases *cannot* always be upgraded with db_upgrade, I thought I was
clear about that.
</pre>
    </blockquote>
    <br>
    The question that started this thread was why a BDB database could
    not be opened. The answer is, because the BDB back-end was not
    built. We don't even know that the old and new BDB versions are
    different.<br>
    <br>
    -- Brane<br>
    <br>
    <br>
    <div class="moz-signature">-- <br>
      <span style="font-face:sans-serif;font-size:9pt;line-height:18pt">Branko
        Čibej <span style="color: #f90">|</span> <span
          style="font-weight:bold">Director of Subversion</span>
        <br>
        WANdisco <span style="color: #f90">//</span> <span
          style="font-style:oblique">Non-Stop Data</span>
        <br>
        <span style="color: #ccc">e.</span> <a class="moz-txt-link-abbreviated" href="mailto:brane@wandisco.com">brane@wandisco.com</a></span></div>
  </body>
</html>

--------------060400010905080608010000--