Closed Bug 318173 Opened 19 years ago Closed 10 years ago

Please remove the "Berkeley DB" partition for mozilla/dbm/* in Despot.

Categories

(mozilla.org :: CVS: Administration, task, P2)

Product:
mozilla.org
Component:
CVS: Administration
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: wtc, Assigned: pavlov)

Details

A while ago, the NSS team determined that NSS is
the only user of the Berkeley DB 1.85 code in
mozilla/dbm/ and got mozilla.org staff's approval
to be the new owner of mozilla/dbm/*.

Since there is an existing "Berkeley DB" partition
for mozilla/dbm/* in Despot, I can't add mozilla/dbm/*
to the "security" partition because the rules would
overlap.

Could you please remove the "Berkeley DB" partition
in Despot?  Otherwise, the NSS team will need to copy
the files in mozilla/dbm/ to mozilla/security/dbm/,
which may not be a bad idea because mozilla/dbm is part
of the SeaMonkeyAll CVS module and I'm not sure if we
can check out SeaMonkeyAll with one CVS tag and
mozilla/dbm with another CVS tag (the tag for NSS
source files).

Thank you.
If we could move mozilla/dbm to mozilla/security/db (you might lose the 'm', since that is a misnomer perpetrated by Lou Montulli in 1994 when importing the 4.4 BSD db code under the name used by the old v7 Unix dbm library), and eliminate the mozilla/dbm directory altogether, I would be happy.

Note that we have a mozilla/db container to host a plurality of database-like subtrees (same goes for other generic containers, although we don't intend to overdo it here and allow a plurality of implementations most of our modules, or rather of their concepts).

I'm not sure this bug should be owned by justdave.  He won't be making the key decisions, although he may do the CVS deeds.  Anyone else seem better?

/be
Brendan,

As an interim solution, could you add the following
people as the owners of the "Berkeley DB" partition
and put the partition in "Restricted" state in Despot?

julien.pierre.bugs@sun.com
nelsonb@netscape.com
relyea@netscape.com
wtchang@redhat.com

Please also change the "Description" to:
  Berkeley DB 1.85; note misnamed source directory
(In reply to comment #2)
> Brendan,
> 
> As an interim solution, could you add the following
> people as the owners of the "Berkeley DB" partition
> and put the partition in "Restricted" state in Despot?
> 
> julien.pierre.bugs@sun.com
> nelsonb@netscape.com
> relyea@netscape.com
> wtchang@redhat.com

I strongly prefer single owner, so I picked you as owner and made the other three peers, moving shaver and myself to members.

> 
> Please also change the "Description" to:
>   Berkeley DB 1.85; note misnamed source directory

Done, and restricted.

/be


Thanks, Brendan.  I made relyea@netscape.com
the owner because he's our database expert.
That's scraping the bottom of the barrel to consider me a database expert;). More like the only one that calls the database directly;).

Anyway I'm fine with the 'owner' but I would object if Nelson wanted it;).

bob
Do we still need this partition deleted?  It is a separate section of the CVS tree, so it sort of makes sense to leave it a separate partition I suppose.  This would be Brendan's call I guess.
Priority: -- → P2
Closing this out for lack of response in 8 months.  If you still want this, please get the appropriate people to comment and reopen.  (the resolution I'm using is a misnomer, but there doesn't seem to be anything more appropriate)
Status: NEW → RESOLVED
Closed: 18 years ago
QA Contact: chase → justin
Resolution: --- → WONTFIX
Reopening to assign to stuart.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee: justdave → pavlov
Status: REOPENED → NEW
I tend to agree that it would be nice if we could move this directory under security/

Do you guys have any thoughts on doing this?
It'd be nice to have it under security/, and would discourage others from building dependencies on it, but I wouldn't make such a move a precondition for fixing the module definition.  Just my two cents, of course.
yeah, for sure.  Maybe we should file a separate bug for moving the code (hurray, cvs moves) and just go ahead and put dbm under the security module?
Moving mozilla/dbm to mozilla/security/dbm is fine by me if
1) we can move the CVS history of the files, and
2) Mozilla is no longer using any CVS module such as
   SeaMonkeyAll that contains mozilla/dbm.

Bob, Nelson, do you have any objection to moving the mozilla/dbm
files to mozilla/security/dbm?

I agree that moving the mozilla/dbm files can be done in a
separate bug.
If we move the RCS files from mozilla/dbm to mozilla/security/dbm on the CVS server, then we will immediately lose the ability to pull and build NSS 
(including DBM) with any/all old NSS tags.  That would be bad.

Similarly, if we copy the RCS files from mozilla/dbm to mozilla/security/dbm
on the CVS server, and do not alter the copies to remove the old tags, then
in the future when we attempt to pull NSS with an old tag, we will get two 
copies of DBM.  That would also be bad.

So, IMO, the solution is to do all these steps:
0) be sure the master RCS files are backed up somewhere safe before doing 
any of the following steps!
1) copy the RCS files from mozilla/dbm to some temporary directory on the 
CVS server, and then 
2) immediately expunge all the old RCS tags from the new copies of the RCS files, and then 
3) move the newly expunged copies to mozilla/security/dbm on the CVS server,
4) CVS remove the old files in mozilla/dbm.  

The old RCS files will remain on the CVS server in mozilla/dbm, so that we 
will continue to be able to pull old source versions of NSS and rebuild them 
exactly as they were originally built.  Going forward, new tags for NSS will 
tag the copies in mozilla/security/dbm.

Removing tags from copied RCS files can be slightly tricky, especially for
"binary" files (files with a sticky -kb or -ko or -kk tag).  But it can be
done.  We did this once before, but I do not recall which files we moved.
It will require someone with direct (not CVS) access to the master CVS 
source respository, someone who knows RCS files and has nerves of steel. :)
Any volunteers?
(In reply to comment #13)
This is precisely how we already handle cvs moves.  The new files are on the trunk only.  All tags and branches are removed at the destination.  The old files are left in place, and it's the module peers/members responsibility to cvs delete the files from the old location on the trunk.  The current iteration of the script that does all this also resets the timestamps on all of the previous versions at the destination to prevent pulling by date from getting the file in the new location.
Hmmm.  I think we want the branch tag for the currently active branch to also go to the moved/copied rcs file.  More thought required. 
I've removed the Berkeley DB partition from despot and moved |mozilla/dbm/*|
 under the security partition..  Leaving open for now until another bug gets file to move the code.
Pavlov, thanks for fixing this bug.

Moving the mozilla/dbm files in the CVS repository is "highly desirable"
but not a "must-have".  Dave's comment 14 shows that mozilla.org's
CVS administrators have moved files in CVS before and even have
a script.  Bob, Nelson, are you satisfied with Dave's description
of how they handle CVS moves?  If so, I suggest we ask mozilla.org to
move the files in mozilla/dbm to mozilla/security/dbm.
I think we need to preserve the branch tags, but not the static tags,
in all the files we move.  At least one Branch tag needs to be preserved
(that is, copied into the new RCS file) and that is the NSS_3_11_BRANCH tag.  
Comment 14 seems to say that can't/won't happen.  Perhaps I could be 
persuaded that I'm wrong about needing to preserve that branch tag, 
but at the moment, it seems essential.  
Changing QA Contact.
QA Contact: justin → mrz
Status: NEW → RESOLVED
Closed: 18 years ago → 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.