On Sun, Jul 29, 2007, Jeff Johnson wrote:

> On Jul 29, 2007, at 5:03 AM, Ralf S. Engelschall wrote:
>>>
>>> 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?
>>
>> Ok, Thomas and I've looked into the problem in more detail. We cannot
>> bring the frontend and backends into sync without lots of hacking
>> (again, as done in May 2007). So, sorry, we decided to revert the db to
>> the db-ORIG dir again to be in sync again. We'll now look what the best
>> approach is to repeat your import operation so the stuff does not again
>> go out of sync.
>
> May I suggest we use the opportunity to uncouple Berkeley DB from rpm in
> CVS?
>
> I'm not sure how front <-> back end coupling is tying rpm <-> bdb together.

DB and RPM are not coupled together at all. They stay in distinct
modules in CVS and share no files, etc. The coupling is not between
DB and RPM, the coupling is between CVS backend (CVSROOT/history) and
CVSTrac frontend (rpm.db SQLite RDBMS): every file and revision in the
CVS repository has at least one entry in CVSROOT/history and each entry
in CVSROOT/history is related to a record in the rpm.db RDBMS of the
frontend.

The problem is that all this works just fine if one manipulates the CVS
repository via remote CVS commands only. Once one manipulates files on
the server side (like replacing *,v content, etc) one brings the backend
and frontend information out of sync. Once consequence of this is that
the CVS repository browsing via Web partially is broken (in the affected
module).

So, to repeat: WHATEVER HACKING IS DONE, IT _HAS_ TO BE DONE OVER THE
REGULAR CVS COMMAND LINE INTERFACE AND NOT BY MANIPULATING ANYTHING ON
THE SERVER SIDE.

> I am quite sure that the db/* sub-tree is virgin Berkeley DB, always has
> been.

Yes, from a raw data perspective this is the case. Unfortunately,
the data partially lived on the vendor branch (as it was done via
your "track" script) and partially _ONLY_ on the trunk and non-vendor
branches (as it at least DB 4.1.x was imported without "track" and this
way without "cvs import"). Such a mixture is what causes great headache.
With the current re-import we've done we've tried to fix this now. But
forget the "track" script now, it does not work with CVS 1.12 correctly
at all AFAIK.

> There have only been two changes that were rpm related:
>     1) an attempt to handle chroot(2) and paths circa rpm-4.0. Reverted.
>     2) the robust mutex patch from last November, likely being reverted
> too.
>
> Neither of those changes needs to incur whatever cvs overhead is involved.

Currently they got "lost" as we had to use HEAD as the reference point
for the import in order to resolve the mentioned "mixture" from above.
So, if these changes are still required, please commit them again now
to HEAD of the "db" module. They should be not lost again on the next
import. They just got lost once now as we had to resolve the "mixture".

> There is a need for rpm-specific Berkeley DB cvs for various reasons
> (rpm has had early access to undistrinuted sources in the past), but
> that does not mean bdb has to be snarled into a cvs browser for rpm.

We cannot uncouple _this_. The CVStrac frontend operates on the _whole_
CVS backend repository. But it is no problem as long as one doesn't
manipulate files on the server side...

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com