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.

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

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.

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.

73 de jeff