Closed Bug 313699 Opened 20 years ago Closed 19 years ago

resolve impossible Mozilla CVS state

Categories

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

Product:
mozilla.org
Component:
CVS: Administration
Platform:
x86
All
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: chase, Unassigned)

References

Details

Attempting to run automated SCM tools on our CVS repository fails because some files in our repository conflict, making it impossible for them to interpret the intended design of our repository. The following RCS files are problematic: 1. mozilla/cck/ib/script_Linux.ib,v Problem: Improperly formatted RCS file. Possibly superceded by mozilla/cck/ib/script_linux.ib,v. Last modified 2002/03/08. Solution: Remove this RCS file. 2. mozilla/mailnews/mime/resources/content/Attic/mime.js,v Problem: mozilla/mailnews/mime/resources/content/mime.js,v also exists and overrides. Solution: Move Attic/mime.js,v to Attic/mime.js.cvsold,v. 3. mozilla/xpfe/global/resources/content/Attic/printPageSetup.xul,v Problem: mozilla/xpfe/global/resources/content/printPageSetup.xul,v also exists and overrides. Solution: Move Attic/printPageSetup.xul,v to Attic/printPageSetup.xul.cvsold,v. 4. mozilla/xpfe/global/resources/content/Attic/printPageSetup.js,v Problem: mozilla/xpfe/global/resources/content/printPageSetup.js,v also exists and overrides. Solution: Move Attic/printPageSetup.js,v to Attic/printPageSetup.js.cvsold,v. 5. mozilla/xpfe/global/resources/locale/en-US/Attic/printPageSetup.properties,v Problem: mozilla/xpfe/global/resources/locale/en-US/printPageSetup.properties,v also exists and overrides. Solution: Move Attic/printPageSetup.properties,v to Attic/printPageSetup.properties.cvsold,v. 6. mozilla/xpfe/global/resources/locale/en-US/Attic/printPageSetup.dtd,v Problem: mozilla/xpfe/global/resources/locale/en-US/printPageSetup.dtd,v also exists and overrides. Solution: Move Attic/printPageSetup.dtd,v to Attic/printPageSetup.dtd.cvsold,v. 7. mozilla/layout/build/Attic/gbdate.pl,v Problem: mozilla/layout/build/gbdate.pl,v also exists and overrides. Solution: Move Attic/gbdate.pl,v to Attic/gbdate.pl.cvsold,v.
Dave, Brendan: Please review comment 0. If my suggested solutions are appropriate, please note your approval here. I'm interested in alternate suggestions if you have them. Thanks.
moving files to cvsold makes me slightly nervous in that if someone pulls an old version of the source that falls within the range that the old file is active, their source suddenly won't build. On the other hand, that may already be the case, since cvs sees an active file, and it didn't exist yet then, so it might not bother looking in the Attic. I suppose it's better to get the file and have to rename it than the not get it. :)
(In reply to comment #2) > moving files to cvsold makes me slightly nervous in that if someone pulls an > old version of the source that falls within the range that the old file is > active, their source suddenly won't build. The other solution for the conflicting files I considered was to remove them, but they are not simply "dead" files. Some conflicting pairs contain different revisions along the same line of development. The versions not in the Attic are what CVS defaults to in this case of conflict so for all intents and purposes, we could lose the Attic/ file in each pair and be done with it. > On the other hand, that may already be the case, since cvs sees an active file, > and it didn't exist yet then, so it might not bother looking in the Attic. > > I suppose it's better to get the file and have to rename it than the not get > it. :) That was my thinking. We could try moving them and see how the build systems like it. If they stay green and devs don't have difficulty we can leave the repository in the new state. If there is a problem, we can revert the changes easily to get back in the state we're already in.
Status: NEW → ASSIGNED
None of the problem files I listed exist on the Mozilla 1.8 branch. We can fix these problems in the repository without affecting the 1.5 releases.
Second call for comments. Any new feedback on the proposal?
Just wondering if it's known how these arose. Proposed solutions seem ok, would be good to know whether a known CVS bug (or two) bit us. /be
(In reply to comment #6) > Just wondering if it's known how these arose. Proposed solutions seem ok, > would be good to know whether a known CVS bug (or two) bit us. Some of these files are pretty old. I suppose that a CVS bug bit us on one of the malformed RCS files (1 - mozilla/cck/ib/script_Linux.ib,v), but it is severely damaged and shows no actual data in it other than the skeleton of a RCS file. Your guess is as good as mine on this one. For 2 through 6, some of these are files with last commits by rods%netscape.com and scott%scott-macgregor.org ranging between 2000-2003. For 7, something odd happened where the file revision of the RCS file in the attic started at 3.1 on April 13, 2000 and was dead by 3.2 on March 8, 2001. The live file was created at 1.1 on Feb 19, 2001 and has never died. I gather we were hit by CVS bugs in the majority of (if not all) cases.
(In reply to comment #2) > moving files to cvsold makes me slightly nervous in that if someone pulls an > old version of the source that falls within the range that the old file is > active, their source suddenly won't build. FYI I plan to workaround the pull-by-date problem by using the cvs-copy-file.pl script which removes all tags and redates the ,v file to a near present time.
I'm moving forward on implementing these fixes.
Depends on: 321830
Copies for 2 through 7 are done. Removing the original attic files.
2 through 7's original attic files have been removed.
1 (mozilla/cck/ib/script_Linux.ib,v) has been removed from the CVS repository.
Rerunning cvs2svn after introducing these fixes led to: ERROR: A CVS repository cannot contain both /archive/hourly/cvsroot/mozilla/mailnews/addrbook/resources/locale/en-US/ldapAutoCompErrs.properties,v and /archive/hourly/cvsroot/mozilla/mailnews/addrbook/resources/locale/en-US/Attic/ldapAutoCompErrs.properties,v Exited due to fatal error(s). From reviewing mozilla/mailnews/addrbook/resources/locale/en-US/ldapAutoCompErrs.properties it appears it was created on 2005/11/15 by dmose and does not exist on any branches. mozilla/mailnews/addrbook/resources/locale/en-US/Attic/ldapAutoCompErrs.properties,v is presumably the elder, being created on 2004/07/20 and being added to the AVIARY_1_0_20040515_BRANCH by bsmedberg. By being on that branch, it got pulled onto the AVIARY_1_0_1_20050124_BRANCH, so it exists for Firefox and Thunderbird 1.0.x releases, too. What appears to have happened in this case is that bsmedberg checked out a copy of the tree on the Aviary 1.0 branch and cvs added mailnews/addrbook/resources/locale/en-US/ldapAutoCompErrs.properties to it. CVS placed the file in the Attic, showed its base revision (1.1) as being dead and that it had one branch (1.1.0.2) so that development could occur for the Aviary 1.0 branch. On 2005/11/15, dmose ported the file from the 1.0 branch to the trunk and re-added it. This time a copy of the file was placed in the main CVS directory (outside of the Attic) and a conflict between the two arose.
dmose, can you confirm/deny my guess at what happened for ldapAutoCompErrs.properties? mozilla/mailnews/addrbook/resources/locale/en-US/ldapAutoCompErrs.properties could be in Thunderbird's 1.0.1 branch checkout, but I don't see it inspecting crazyhorse (our Thunderbird 1.0.x Linux build system) or in LXR (http://lxr.mozilla.org/aviary101branch/source/mailnews/addrbook/resources/locale/en-US/). I expect the trick of CVS copying the Attic version to ...properties.cvsold and removing the Attic version will bust Thunderbird on the 1.0.x branch. Am I misreading the ,v file? Is ldapAutoCompErrs.properties not actually alive on the AVIARY_1.0.1 branch? If it is alive, my recollection is that CVS sucks, but not this bad. I thought it handled this case of "a file was added only on a branch, then later someone added it to the trunk" more gracefully (viz. by moving the file out of the Attic and reviving it on the trunk line of revisions).
(In reply to comment #8) > FYI I plan to workaround the pull-by-date problem by using the cvs-copy-file.pl > script which removes all tags and redates the ,v file to a near present time. Won't that fail to have the advantage mentioned in the last sentence of comment 2? (FWIW, the other messy CVS state that I've seen is a file being in Attic but not in a "dead" state. It then shows up when pulling by date but not when pulling the trunk. That can be fixed from a client, though, by checking out by the current date (maybe then editing CVS/Entries to remove the sticky date) and then cvs removing normally from the client. A year or so a go I found all such files in the repository (I have a script for it somewhere) and fixed them.) (In reply to comment #14) > mozilla/mailnews/addrbook/resources/locale/en-US/ldapAutoCompErrs.properties > could be in Thunderbird's 1.0.1 branch checkout, but I don't see it inspecting > crazyhorse (our Thunderbird 1.0.x Linux build system) or in LXR Presumably because CVS doesn't examine the file in the Attic because of the file not in the Attic that's shadowing it. > I expect the trick of CVS copying the Attic version to ...properties.cvsold > and removing the Attic version will bust Thunderbird on the 1.0.x branch. Why, if it's not busted already? If it's not showing up in checkouts, then how would that make things worse? > Am I misreading the ,v file? Is ldapAutoCompErrs.properties not actually alive > on the AVIARY_1.0.1 branch? Which ,v file? The one in Attic looks alive and well on AVIARY_1_0_1_20050124_BRANCH > If it is alive, my recollection is that CVS sucks, but not this bad. I thought > it handled this case of "a file was added only on a branch, then later someone > added it to the trunk" more gracefully (viz. by moving the file out of the > Attic and reviving it on the trunk line of revisions). I thought it did too. It could be that the server trusts that the client has done this correctly, and if somebody uses a local method of cvs add that doesn't ping the server, it'll break. That's a completely uneducated guess, though.
(In reply to comment #15) > (In reply to comment #8) > > FYI I plan to workaround the pull-by-date problem by using the cvs-copy-file.pl > > script which removes all tags and redates the ,v file to a near present time. > > Won't that fail to have the advantage mentioned in the last sentence of comment > 2? If the tags weren't removed, the dates weren't changed, copying the files to .cvsold,v would make the .cvsold files show up in the old checkouts where the originals haven't appeared since their non-Attic counterparts were added. Since the Attic files were already missing from the checkouts, then a method was selected that would mimic that behavior by ensuring the files don't show up in anything but the latest trunk checkout as of today. I see no purpose for keeping 2-7 other than as historical artifacts. I still have the originals. If you have another suggestion which would satisfy a particular concern, we can still consider it. > (FWIW, the other messy CVS state that I've seen is a file being in Attic but > not in a "dead" state. It then shows up when pulling by date but not when > pulling the trunk. That can be fixed from a client, though, by checking out by > the current date (maybe then editing CVS/Entries to remove the sticky date) and > then cvs removing normally from the client. A year or so a go I found all such > files in the repository (I have a script for it somewhere) and fixed them.) That sounds like what happened to the ldapAutoCompErrs.properties file. It was added only to a branch, which placed the file in the Attic, marked it dead on the trunk, and alive on the branch. I'd like to see your script. Is it on megalon? > (In reply to comment #14) > > mozilla/mailnews/addrbook/resources/locale/en-US/ldapAutoCompErrs.properties > > could be in Thunderbird's 1.0.1 branch checkout, but I don't see it inspecting > > crazyhorse (our Thunderbird 1.0.x Linux build system) or in LXR > > Presumably because CVS doesn't examine the file in the Attic because of the > file not in the Attic that's shadowing it. Yes, of course. I'd forgotten that in this bug's details. > > I expect the trick of CVS copying the Attic version to ...properties.cvsold > > and removing the Attic version will bust Thunderbird on the 1.0.x branch. > > Why, if it's not busted already? If it's not showing up in checkouts, then how > would that make things worse? Good point. > > Am I misreading the ,v file? Is ldapAutoCompErrs.properties not actually alive > > on the AVIARY_1.0.1 branch? > > Which ,v file? The one in Attic looks alive and well on > AVIARY_1_0_1_20050124_BRANCH The Attic ,v file. It reads like it's alive on the branch, but since it doesn't show up in checkouts one can only presume the non-Attic version is taking precedence. My understanding, then, is that from 2004/07/20 to 2005/11/14 ldapAutoCompErrs.properties was part of 1.0/1.0.1 branch pulls. On 2005/11/15 when ldapAutoCompErrs.properties was added to the trunk, it went missing from 1.0/1.0.1 branch pulls. > I thought it did too. It could be that the server trusts that the client has > done this correctly, and if somebody uses a local method of cvs add that > doesn't ping the server, it'll break. That's a completely uneducated guess, > though. I'd like to find out how dmose added this file to the trunk.
I think the ldapAutoCompErrors story is even nastier than Chase inferred. That file originally lived in mozilla/xpfe/components/autocomplete/resources/locale/en-US. About two months ago, bsmedberg landed a patch that moved it into mailnews <https://bugzilla.mozilla.org/show_bug.cgi?id=263042#c15>. Note, however, in comment 14, I suggested using symlink hackery behind the scenes to avoid losing CVS history, and I suspect that's what happened, maybe Benjamin remembers exact details. Now, interestingly, doing a "cvs log" on that file lies about the revision dates for at least revs 1.1 and 1.2 (they landed years ago, probably long before Thunderbird even existed). Additionally, "cvs log" on the file claims that there are no tags on it, which is not what I would expect if the file were actually symlinked.
Probably relevant is that I did both aforementioned "cvs log" commands in a tree checked out from the trunk.
See bug 314830.
(In reply to comment #16) > I'd like to find out how dmose added this file to the trunk. (In reply to comment #19) > See bug 314830. bsmedberg filed a request (bug 314830) to copy the original autocomplete file (xpfe/components/autocomplete/resources/locale/en-US/ldapAutoCompErrs.properties) to a new location (mailnews/addrbook/resources/locale/en-US/ldapAutoCompErrs.properties). I complied and, in so doing, the ldapAutoCompErrs.properties in the Attic became obsolete. The copy took place on 2005/11/15, as can be seen in the non-Attic version and in bug 314830.
A couple things to prevent this in the future: * Change copy-cvs-file.pl to verify that there is no file in the Attic by that name already. * Verify all of the files to be copied are first eligible to be copied by running that verify routine on the cvsmoves file with a command like process-cvsmoves.pl. On recovering, since no commits have been made to the non-Attic ldapAutoCompErrs.properties, I suggest we remove that file and then resurrect it as CVS would expect (by adding it to the trunk with the cvs command).
(In reply to comment #21) > A couple things to prevent this in the future: > > * Change copy-cvs-file.pl to verify that there is no file in the Attic by > that name already. It already does, in theory. my $atticfile = dirname($destfile) . "/Attic/" . basename($destfile); -e $atticfile && die "$atticfile already exists\n"; Either something's broken with the above code or that isn't the script that was used for the move...
(In reply to comment #22) > (In reply to comment #21) > > A couple things to prevent this in the future: > > > > * Change copy-cvs-file.pl to verify that there is no file in the Attic by > > that name already. > > It already does, in theory. > > my $atticfile = dirname($destfile) . "/Attic/" . basename($destfile); > -e $atticfile && die "$atticfile already exists\n"; > > Either something's broken with the above code or that isn't the script that was > used for the move... It's being used differently now. The checks need to be added to its current usage, too.
Went over this with bsmedberg on IRC. To fix the ldapAutoCompErrs.properties issue, I'm going to remove the non-Attic version from the repository and he'll revive the file on the trunk. The revival should pull the Attic version out of the Attic and mark it alive. At that point I'll forge the revive date so it matches the first trunk revision of the original non-Attic version. This will make the new non-Attic version appear in checkouts by dates set to when the copy took place.
The issues surrounding ldapAutoCompErrs.properties have been resolved.
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build
Status: ASSIGNED → NEW
(In reply to comment #25) > The issues surrounding ldapAutoCompErrs.properties have been resolved. > Can we resolve this bug? If not, maybe we should either open a new one or change the summary (unless there are other "impossible" states that CVS is in right now that are not listed here). It seems like the gist of the bug is to get CVS into a state that the cvs2svn importer can handle, if it's still a problem that might be a better summary.
Since I've been out of the game, I've not been on this one. Feel free to resolve or pick it up and run with it.
Ok, resolving for now.. I'll reopen or open a new one if there are still problems w/ cvs2svn specifically or any other CVS inconsistencies in general.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.