853749 - Move NSPR from nsprpub/ to nspr/

Status: REOPENED

(Firefox Build System :: General, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: Update references to nsprpub/ to refer to nspr/ instead

When we decided to move NSPR from CVS to Mercurial we also decided to rename the top-level directory from nsprpub/ to nspr/ to match the name of the NSPR Mercurial repository (https://hg.mozilla.org/projects/nspr). This bug is about doing that moving.

I am doing this as an "hg mv" so as to preserve the limited history that we have for nsprpub/. We don't have patch-by-patch history in mozilla-central because of the way we have imported NSPR from CVS. In the future I hope to enable patch-by-patch history during these merges, but there are some complications to that.

It would be great to get this done soon so that it doesn't block the rest of the CVS-to-Mercurial-related stuff.

To make the patch easier to review, I did not include the actual "hg mv nsprpub/ nspr/" part of the patch. Before landing, I will combine this patch with that changeset so as to not break the build.

Question: Will this require the use of the CLOBBER mechanism?

I will also announce this on dev-platform when I do the landing. I will also update the "Modules" page on the wiki. The "Updating NSPR and NSS in mozilla-central" document will be edited separately as part of the bug that updates the client.py script to pull NSPR from Mercurial instead of CVS.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

https://tbpl.mozilla.org/?tree=Try&rev=5e17041dc818

Comment 2

[Gregory Szorc [:gps]]

Possibly crazy idea: when importing NSPR from Mercurial, we import it to /nspr with full version history instead of doing an hg mv. Is there a benefit to having full history duplication in m-c? If not, why are you proposing patch-by-patch history during future merges instead of bulk imports?

Also, now that NSPR is in Mercurial, have we considered subrepositories [1]? I confess to not knowing if that feature is usable. [2] says it is a "feature of last resort." It even calls out "Mozilla" as a counter case why it isn't necessary. Just want to be sure we've thought of all the options...

[1] http://mercurial.selenic.com/wiki/Subrepository
[2] http://mercurial.selenic.com/wiki/FeaturesOfLastResort

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Gregory Szorc [:gps] from comment #2)
> Possibly crazy idea: when importing NSPR from Mercurial, we import it to
> /nspr with full version history instead of doing an hg mv. Is there a
> benefit to having full history duplication in m-c? If not, why are you
> proposing patch-by-patch history during future merges instead of bulk
> imports?

The main benefit to patch-by-patch history is that "hg bisect" will be become useful for finding regressions caused by specific NSPR (and NSS) changes. That's why I want to enable it in the future. If/when we do that, we will probably end up importing in the entire NSPR history at the time we implement that. But, it would be confusing to import in the entire version history of NSPR before we have the ability to do incremental updates that preserve the patch-by-patch history. I do not have time to things the proper way. The goal of this bug is simply to port the mechanism we have currently from CVS to Mercurial.

I am doing the "hg mv" instead of just blowing away nsprpub/ and importing NSPR into nspr/ because there is some useful history for mozilla-central's nsprpub/. In particular, the history of private patches and the timestamps of the imports from CVS may be useful. I don't want to destroy that history, at least unless/until I have something better (e.g. the patch-by-patch history) to replace it with.

> Also, now that NSPR is in Mercurial, have we considered subrepositories [1]?
> I confess to not knowing if that feature is usable. [2] says it is a
> "feature of last resort." It even calls out "Mozilla" as a counter case why
> it isn't necessary. Just want to be sure we've thought of all the options...
> 
> [1] http://mercurial.selenic.com/wiki/Subrepository
> [2] http://mercurial.selenic.com/wiki/FeaturesOfLastResort

Yes, we can consider that in the future. I know that joduinn was opposed to the subrepository feature, having previously investigated it. Also, I don't think it would work well for people that prefer to use the git interface to mozilla-central instead of Mercurial. And, I don't think we should make long-term plans based on the assumption that mozilla-central and NSPR or NSS will use the same version control system. In particular, Bob Relyea is very against switching to Git but I know that people are seriously considering switching mozilla-central to git. I do not want to create any impediments to that.

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

The results of the try run look good:
https://tbpl.mozilla.org/?tree=Try&rev=5e17041dc818

Comment 5

[(not currently active) Ted Mielczarek]

I don't really get the benefit here. We renamed the hg repo, but we can just keep cloning it as "nsprpub" in mozilla-central to avoid churn. Why do you want do to this?

Comment 6

[Benjamin Smedberg]

Indeed, this seems like useless makework. We can change the NSPR repository name without changing its mozilla-central import.

Comment 7

[Kai Engert [:KaiE:]]

+1 to avoiding unnecessary changes.

Comment 8

[(not currently active) Ted Mielczarek]

Okay, WONTFIXing this unless there's a better justification.

Comment 9

[Wan-Teh Chang]

Comment on attachment 728073 [details] [diff] [review]
Update references to nsprpub/ to refer to nspr/ instead

Review of attachment 728073 [details] [diff] [review]:
-----------------------------------------------------------------

r=wtc. I would not have done this, but since Brian has written and tested
the patch, I think it is fine to check this in, unless moving nsprpub to
nspr will cause some hg problems...

Comment 10

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Hi guys. I don't want to spend too much time on this. I think that, if we were to import NSPR into the tree today, we would put it in a directory named "nspr" not "nsprpub." The "pub" suffix is unclear to people, especially people who don't understand the history of non-open-source NSPR. In the last couple of years, we've made much more disruptive changes (PRBool -> bool, PR[U]intX -> [u]intX_t, and more) in the name of making things more clear. This is in the same spirit and is even less disruptive, since it only affects configuration files. It is more important to make things clear for newcomers than it is to avoid inconvenience for the people that are used to the way things are currently done.

Anyway, IIRC, Brendan (the top-level module owner) and Wan-Teh (the NSPR module owner) both independently expressed support for doing this. It was so long ago that I cannot remember if their support was strong ("we MUST do this") or weak ("If you do that, I won't hate you too much, but I'd rather not."). I will let them speak for themselves. (Edit: I see Wan-Teh just commented saying it is more "if you do that, I won't hate you too much." for him.)

Comment 11

[Benjamin Smedberg]

I absolutely agree that if we were doing it today, we'd probably at least import it into nspr instead of nsprpub. I suspect that we would also probably use subrepos, although I'm interested to hear what about them joduinn found unworkable.

Unlike uint32_t, I don't think that moving the code from nsprpub to nspr will prove a significant improvement to contributor understanding of the code, and it has the downside of breaking MXR/DXR links in bugzilla and on devmo. It doesn't seem like the same kind of win.

The thing that I most oppose about this is importing the entire NSPR history into mozilla-central. I do not think that in general, people who are bisecting mozilla-central should be exposed to the NSPR history tree, as it is rarely relevant and dealing with tags could be a pain.

Comment 12

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #11)
> I suspect that we would also probably use subrepos, although I'm
> interested to hear what about them joduinn found unworkable.

Yes, I would like to know to. I just vaguely remember joduinn telling me that subrepos would probably be problematic and I didn't inquire further.

> The thing that I most oppose about this is importing the entire NSPR history
> into mozilla-central. I do not think that in general, people who are
> bisecting mozilla-central should be exposed to the NSPR history tree, as it
> is rarely relevant and dealing with tags could be a pain.

I'm not sure what you mean about the tags. Note that using the subrepos feature is very much the same thing, AFAICT. This is one reason that the subrepos feature is probably not good for us--it would significantly increase the time needed to clone mozilla-central if we used it for both NSPR and NSS.

Anyway, I am happy to leave this WONTFIX unless/until Wan-Teh and/or Brendan disagree. I thought I had committed to doing this based on their requests but it is possible that I am mis-remembering long-ago conversations.

Comment 13

[Wan-Teh Chang]

I support moving NSPR from nsprpub/ to nspr/.

We will need to move three NSS directories:
  dbm/ to security/nss/lib/dbm/
  security/dbm/ to security/nss/lib/dbm/
  security/coreconf/ to security/nss/coreconf/

So this is an unusual opportunity to rename nsprpub/.

Comment 14

[Brendan Eich [:brendan]]

a=me, thanks.

/be