Closed
Bug 477257
Opened 15 years ago
Closed 15 years ago
Sisyphus checkout fails when nsprpub/configure fails to merge
Categories
(Testing Graveyard :: Sisyphus, defect)
Testing Graveyard
Sisyphus
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bc, Assigned: bc)
Details
When nsprpub/configure changes, the hg update fails due to conflicts in nsprpub/configure's merge. This is a continual pita. I could do an hg update -C but that will automatically throw away local changes. I'll do this locally for a short term fix, but Clint, do you have any other suggestions?
Yeah, I have noticed a bunch of people complaining about this, but I don't have any suggestions. CC'ing bsmedberg in hopes he can enlighten us as to what's going on.
Comment 2•15 years ago
|
||
Who is regenerating nsprpub/configure? As far as I know we shouldn't be generating it automatically. If we are, that sounds like a bug in client.mk If you're regenerating it on purpose, then of course you have to deal with merge conflicts. The right way to deal with them is re-run autoconf-2.13 in the nsprpub directory.
(In reply to comment #2) > Who is regenerating nsprpub/configure? As far as I know we shouldn't be > generating it automatically. If we are, that sounds like a bug in client.mk It seems like there is a set of nsprpub changes that appear in an hg tree after every pull even if the pull didn't bring anything down. This means when you get ready to do an hg outgoing, you have a bunch of nsprpub changes in your set. I've seen this behavior, though I'm no Hg expert. Let me see if I can get you a reproducible scenario and we can see if it is indeed a bug with client.mk.
Assignee | ||
Comment 4•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/3e2e6a538627
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Updated•5 years ago
|
Product: Testing → Testing Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•