RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Upgrading to db-4.6 internal

From: Ralf S. Engelschall <rse+rpm-devel@rpm5.org>
Date: Sun 29 Jul 2007 - 10:54:06 CEST
Message-ID: <20070729085406.GA66142@engelschall.com>
On Sat, Jul 28, 2007, Jeff Johnson wrote:

>> Ohhhhhh, well, yes, seems like I've suppressed this experience ;-)
>> As long as you are careful and not create new symlinks in the CVS
>> repository everything should be still fine...
>
> OK. Just to get warmed up, I dragged track et al onto rpm5.org
> with db-4.5.20 and db-4.6.18 tarballs for import into a private
> cvs repository.
>
> After a few false starts getting setup (root checkins are prohibited),
> cvs on rpm5.org running on private repository as user jbj:jbj segfaults.
>
> Same command(s) on F7 work just fine:
>     export CVSROOT=`pwd`/master
>     cvs init
>     tar xzvf db-4.5.20.tar.gz
>     cd db-4.5.20
>     track -o db -v vendor
>     cd ..
>     tar xzvf db-4.6.18.tar
>     cd db-4.6.18
>     track -v vendor
>
> (just exit and yes where asked is sufficient for track)
> [...]
> So I grabbed a tarball of /v/rpm/cvs/db and dragged it back to F7 to do the
> vendor import.
>
> The result of that merge I will place in a top level "db46" module, which
> will
> be good enuf for me to figger whether rpm-5.0 builds by doing an additional
>     cvs -d ... get -d db db46
> in a HEAD tree.

Thanks for all your efforts, Jeff.

But unfortunately, although this procedure correctly upgraded db/
subdir content, you missed to append the corresponding entries to
CVSROOT/history! This way the CVSTrac frontend and the CVS backend are
out of sync!! And because you already made two new commits we cannot fix
it easily by _NOW_ appending the CVSROOT/history entries (as the two new
entries were already taken over into the CVSTrac SQLite RDBMS)...

As I said multiple times in the past, whatever you do, you always
_HAVE_ to go through the "cvs" command line and _NEVER EVER_ touch
the repository manually. Replacing content on the server side gets
the backend and frontend totally out of sync and it cannot be fixed
afterwards easily.

Puhh.... may I suggest that we reverse this again by moving
/v/rpm/cvs/db-OLD into place again and _I_ do your above procedure again
by using the regular remote CVS access?

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com
Received on Sun Jul 29 10:54:26 2007
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.