Closed Bug 76856 Opened 25 years ago Closed 22 years ago

cvs bug checks out deleted files into local copies and corrupts builds

Categories

(mozilla.org Graveyard :: Server Operations, task, P1)

Product:
mozilla.org Graveyard
Component:
Server Operations
Platform:
All
Other
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: btiffany, Assigned: justdave)

References

Details

Attachments

(1 file)

Updated list of files to remove
2.14 KB, text/plain
Details
A bug has been identified in CVS v1.11 that affects mozilla's cvs servers. If you use checkout -D <now> SeaMonkeyAll you get ~39 more files than if you use checkout SeaMonkeyAll. Some of these are duplicate header files that break tinderboxes (os/2). Suggest that all of these be cvs -removed (again) and all tinderbox maintainers be advised to use checkout -D (a.k.a. moz_co_date argument to client.mk) to detect "recreated" files as soon as they happen. This actually broke os/2 about 4 weeks ago but we didn't unlayer it until now. Attached is an excerpt from the CVS discussion group explaining the problem. On Thu, Apr 19, 2001 at 03:11:46PM -0500, Bruce Tiffany wrote: > I believe I've found the source of my confusion. When a file is deleted > in > CVS, then revised by another user, cvs checkout will not produce the file, > however cvs checkout -D <now> will. I'm uncertain if that's a bug or a > feature, use of checkout -D ... seems to be the safer way to go. Looks like a bug to me. Tested with CVS 1.11, all actions performed on the trunk: > Time User 1 User 2 > ---- -------------------- ------------------------------ > > | cvs checkout proj1 cvs checkout proj1 > | rm foo > | cvs -remove foo > \|/ cvs commit Does what you'd expect -- checks in a "dead" revision and moves the ,v file to the attic. > edit foo Note that a "cvs commit" here correctly reports "Up-to-date check failed for `foo'". > cvs update Says: $ cvs update cvs update: Updating . RCS file: /home/erics/t2/Repos/p/Attic/foo,v retrieving revision 1.1 retrieving revision 1.2 Merging differences between 1.1 and 1.2 into foo foo already contains the differences between 1.1 and 1.2 $ Shouldn't it have reported a conflict? > cvs commit Commits User 2's text as a new undead revision (ie. state="Exp"), but DOES NOT move the ,v file back out of the Attic, thus violating this constraint, as documented in the manual, node "Attic": [...] the rule is that the RCS file is stored in the attic if and only if the head revision on the trunk has state `dead'. The reported inconsistency between "cvs checkout" and "cvs checkout -D now" follows from this. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont. erics@telepres.com | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://mail.gnu.org/mailman/listinfo/info-cvs
Here is a list of files that appear in a local copy when running cvs checkout - D <now> but not when running cvs checkout. I've randomly examined about 15% of them using cvs -log, all have a revision to "dead" followed by subsequent revisions, to, shall we say, undead? So I think these are the "living dead" that only come out at -D.... :-) mozilla/content/xul/content/src/nsXULAtomList.h mozilla/docshell/base/nsDocShellBase.cpp mozilla/dom/src/css/nsJSCSSStyleRuleSimple.cpp mozilla/dom/src/events/nsJSTextRange.cpp mozilla/gfx/src/ps/nsGfxFactoryWin.cpp mozilla/htmlparser/src/nsHTMLParser.cpp mozilla/htmlparser/src/nsTokenizer.cpp mozilla/htmlparser/src/nsTokenizer.h mozilla/layout/base/public/nsLayoutAtomList.h mozilla/layout/html/base/src/nsFrameTraversal.cpp mozilla/layout/html/base/src/nsHTMLImage.cpp mozilla/layout/html/base/src/nsHTMLTagContent.cpp mozilla/layout/html/forms/src/nsInputFrame.cpp mozilla/mailnews/base/resources/content/dbviewtest.xul mozilla/mailnews/base/src/nsDecodeAppleFile.h mozilla/mailnews/compose/prefs/resources/content/pref-messages.xul mozilla/mailnews/compose/src/nsComposeAppCore.cpp mozilla/mailnews/db/msgdb/public/nsIDBChangeListener.h mozilla/profile/pref-migrator/src/nsPrefMigrationProgressDialog.cpp mozilla/profile/resources/cpw.xul mozilla/rdf/base/src/nsRDFContentSink.h mozilla/rdf/datasource/src/nsMailDataSource.h mozilla/webshell/tests/viewer/nsUnixMain.cpp mozilla/webshell/tests/viewer/winmain.cpp mozilla/widget/src/nsImageButton.cpp mozilla/widget/src/gtk/nsWidgetSupport.cpp mozilla/xpfe/browser/resources/content/openLocation.xul mozilla/xpfe/browser/src/navigator.xul mozilla/xpfe/components/bookmarks/resources/bm-panel.xul mozilla/xpfe/components/history/src/nsSHEntry.cpp mozilla/xpfe/components/prefwindow/resources/content/pref-cookies.xul mozilla/xpfe/components/prefwindow/resources/content/pref-images.xul mozilla/xpfe/components/prefwindow/resources/content/pref-passwords.xul mozilla/xpfe/components/prefwindow/resources/content/pref-wallet.xul mozilla/xpfe/components/prefwindow/resources/content/prefutilities.js mozilla/xpfe/components/prefwindow/resources/locale/en-US/pref-cookies.dtd mozilla/xpfe/components/prefwindow/resources/locale/en-US/pref-images.dtd mozilla/xpfe/components/prefwindow/resources/locale/en-US/pref-passwords.dtd mozilla/xpfe/components/prefwindow/resources/locale/en-US/pref-wallet.dtd
Hardware: PC → All
Here is a list of files that appear in a local copy when running cvs checkout - D <now> but not when running cvs checkout. I've randomly examined about 15% of them using cvs -log, all have a revision to "dead" followed by subsequent revisions, to, shall we say, undead? So I think these are the "living dead" that only come out at -D.... :-) mozilla/content/xul/content/src/nsXULAtomList.h mozilla/docshell/base/nsDocShellBase.cpp mozilla/dom/src/css/nsJSCSSStyleRuleSimple.cpp mozilla/dom/src/events/nsJSTextRange.cpp mozilla/gfx/src/ps/nsGfxFactoryWin.cpp mozilla/htmlparser/src/nsHTMLParser.cpp mozilla/htmlparser/src/nsTokenizer.cpp mozilla/htmlparser/src/nsTokenizer.h mozilla/layout/base/public/nsLayoutAtomList.h mozilla/layout/html/base/src/nsFrameTraversal.cpp mozilla/layout/html/base/src/nsHTMLImage.cpp mozilla/layout/html/base/src/nsHTMLTagContent.cpp mozilla/layout/html/forms/src/nsInputFrame.cpp mozilla/mailnews/base/resources/content/dbviewtest.xul mozilla/mailnews/base/src/nsDecodeAppleFile.h mozilla/mailnews/compose/prefs/resources/content/pref-messages.xul mozilla/mailnews/compose/src/nsComposeAppCore.cpp mozilla/mailnews/db/msgdb/public/nsIDBChangeListener.h mozilla/profile/pref-migrator/src/nsPrefMigrationProgressDialog.cpp mozilla/profile/resources/cpw.xul mozilla/rdf/base/src/nsRDFContentSink.h mozilla/rdf/datasource/src/nsMailDataSource.h mozilla/webshell/tests/viewer/nsUnixMain.cpp mozilla/webshell/tests/viewer/winmain.cpp mozilla/widget/src/nsImageButton.cpp mozilla/widget/src/gtk/nsWidgetSupport.cpp mozilla/xpfe/browser/resources/content/openLocation.xul mozilla/xpfe/browser/src/navigator.xul mozilla/xpfe/components/bookmarks/resources/bm-panel.xul mozilla/xpfe/components/history/src/nsSHEntry.cpp mozilla/xpfe/components/prefwindow/resources/content/pref-cookies.xul mozilla/xpfe/components/prefwindow/resources/content/pref-images.xul mozilla/xpfe/components/prefwindow/resources/content/pref-passwords.xul mozilla/xpfe/components/prefwindow/resources/content/pref-wallet.xul mozilla/xpfe/components/prefwindow/resources/content/prefutilities.js mozilla/xpfe/components/prefwindow/resources/locale/en-US/pref-cookies.dtd mozilla/xpfe/components/prefwindow/resources/locale/en-US/pref-images.dtd mozilla/xpfe/components/prefwindow/resources/locale/en-US/pref-passwords.dtd mozilla/xpfe/components/prefwindow/resources/locale/en-US/pref-wallet.dtd
*** Bug 76855 has been marked as a duplicate of this bug. ***
Is it a bug in the client or the server? cvs.mozilla.org is still running 1.10.7. I have no idea what the servers at sourceforge are running.
Assignee: cls → endico
Priority: -- → P1
It's a bug in the CVS server, V1.11 has it and your servers have it too. The server doesn't handle the repository properly when a file is revised from dead to alive state. Once that's occured, checkout behaves inconsistently depending on whether -D is used or not. -D will cause all the improperly handled files to appear in the tree so they can be dealt with.
More info on this bustage since it is happening on all the *IX TBs right now. It appears to happen when a file that has been cvs removed gets a change made to it after the fact.
[endico@cvs-mirror endico]$ cvs -v Concurrent Versions System (CVS) 1.10.8 (client/server)
We were hit by this bug today with mozilla/gfx/src/gtk/scale.c. The file was succesfully re-killed with: rm scale.c cvs remove scale.c cvs commit scale.c Proof that even the living dead are not immortal!
Can I get permission to rekill the files listed by bruce? This will involve checking out a tree by date, rming the file and then cvs removing it. Anyone object?
moving over to scbrown for the issue of updating our cvs server. Someone else (seawood?) needs to review Kaply's suggested change to work around the problem.
Component: Build → Server Operations
Product: Webtools → mozilla.org
More info on how to kill the file. cvs update the file to the most recent revision (the one after dead) so the file comes back in the directory. Then to a cvs update -l -A to bring the sticky tags up to date - the file will not disappear. then rm filename cvs remove filename cvs commit filename
I don't see any suggestions here on how to work around the cvs problem but I agree that the files should be removed again. Here's an updated list. I pulled two trees, a normal build and one by date, and compared the file lists. I then checked lxr for any references to the difference files.
There were a couple of files that were still referenced in lxr by files that we also don't build by default so I'm not sure if they're still needed or not. mozilla/htmlparser/src/nsTokenizer.h mozilla/layout/html/forms/src/nsGfxTextControlFrame.cpp and mozilla/mailnews/base/src/nsDecodeAppleFile.h should be removed as well.
Hmmm, it would be nice if you wouldn't blindly trust some theory and actually see if these files were still in use... mozilla/xpfe/browser/resources/content/openLocation.xul mozilla/xpfe/browser/src/navigator.xul mozilla/xpfe/components/bookmarks/resources/bm-panel.xul mozilla/xpfe/components/history/src/nsSHEntry.cpp These aren't dead files. I'm sure a whole bunch of the others aren't either. Please fix this.
I take that back. Only navigator.xul seems to have been incorrectly removed.
(Man, you don't look for a second and the world changes from under you ;-)
Strange things ARE afoot. I'm not sure why openLocation.xul is in our list, it is not a dead file. and when I tried to remove navigator.xul, it took out the other navigator.xul. Weird. I'm going to quit for now to make sure nothing breaks
dead: mozilla/xpfe/browser/resources/content/openLocation.xul not dead: mozilla/xpfe/communicator/resources/content/openLocation.xul That should explain it (and that's what fooled me the first time around) :-)
reassigning to scbrown
Assignee: endico → scbrown
QA Contact: matty → endico
Moving tickets to Ray.
Assignee: scbrown → daruszka
cvs.mozilla.org has been upgraded to version 1.11.1p1 (bug 72505), so this problem should be fixed.
Mass changing IC's ticket to reflect current situation. mozilla.org, AOL employees: If you want IC to look at issues reported in bugzilla, please open a Helpdesk ticket and ask it to be routed to AOL R1 Server Operations. We currently have no way to handle comprehensive problem resolution through bugzilla. This is not a change in the way we are supporting mozilla.org - we are still supporting you on the level as before. IC's support is based on Helpdesk ticket system - not bugzilla which only few hard-core people are looking at. Also, projects are handled elsewhere - not in bugzilla. If you have projects you need us to deliver please feel free to contact me directly. Summa summarum: tickets -> Helpdesk Project initiations -> RKotalampi@aol.com
Assignee: daruszka → nobody
The current cvs server is running: [root@megalon ~]# cvs -v Concurrent Versions System (CVS) 1.11.4 (client/server) Is this still an issue?
Assignee: nobody → justdave
OK, found this in CVS's issue tracker... http://ccvs.cvshome.org/issues/show_bug.cgi?id=79 According to that bug, it's fixed in 1.11.2, so resolving.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: