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)

defect
Not set
normal

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.
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.
http://hg.mozilla.org/mozilla-central/rev/3e2e6a538627
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.