[oi-dev] userland history problems

[Bayard Bell]

I've got a cleaned up repo ready and will push it to the canonical
later. A summary of changes:

1) this is based off the userland-gate/oi-build history (that's where
revision 0 now starts)
2) the history has been made linear; for three out of four merges in
the history, this was a no-op; for the fourth (rev 445 in the new
history was previously part of a merge but is not an initial import of
changes for the illumian build system, which still requires issue
2160/rev 448 for clean-up)
3) Nexenta copyrights were written twice to cpan2ips and py2ips; these
have been de-duped (rev 464)
4) changes that were backed out (and obviously the backouts were
removed, as these simply make for noise in a lot of places when trying
to read back through annotations)
5) two userland-gate changes that were lacking a space separator
between name and address in the user field have been fixed (revisions
359 and 404)
6) the one tag assignment subsequent to these changes has been altered
to reflect the altered change signatures (build-170 assigned to rev
378 via rev 380)

I've confirmed via hg fetch from the current illumos-userland and then
hg-recommit that there are no unaccounted-for differences (the only
differences are the difference in .hgtags resulting from signature
differences and an extraneous line feed removed as part of the Nexenta
copyright de-dup). I've also gotten peer review on the rebuild from
andy_js.

I'm going to confirm that everything is good to go for git by building
hg-git/dulwich, importing, running git fsck, and pushing to github.
The mirror on hg.oi.o will lag somewhat behind cleaning the canonical,
as it will need to be stomped and re-cloned before mirroring can be
resumed. At that point the illumos-infra folks can provide github
mirroring for us.

If you have clones out there for issues, what I'd suggest is waiting
until there's an illumos/illumos-userland to clone from. Take what
you've got in your issue clone, push it to bitbucket for backup ("hg
push ssh://hg@bitbucket.org/<userid>/illumos-userland-<issue>"),
export the changes (e.g. "hg export -g -o ~/illumos-userland.<issue>
tip"--you will need to do this for additional revisions between the
canonical tip and the local if you have multiple changesets for the
issue), stomp the local repo ("hg strip 0"), re-path it to the
canonical (edit .hg/hgrc off the top of the clone to set "default =
ssh://hg@bitbucket.org/illumos/illumos-userland"), sync to the local
clone ("hg fetch"; if you haven't enabled the fetch extension, add
"fetch = " in the "[extensions]" section of ~/.hgrc), and then import
your changes back in ("hg import ~/illumos-userland-<issue>"). Do an
"hg outgoing ssh://hg@bitbucket.org/illumos/illumos-userland" to
confirm that the changes you've imported all show up.

Please note that ssh://hg@bitbucket.org/illumos/illumos-userland does
not yet exist, and it shouldn't exist until the canonical's been
sorted.

Cheers,
Bayard

On Thu, Apr 12, 2012 at 11:12 PM, Alasdair Lumsden <alasdairrr at gmail.com> wrote:
> Hi Bayard,
>
> Sorry for not getting back to you sooner - I think the answer is "go for it".
>
> We only get this opportunity once, so lets take it. The hassle factor is worth it, checking out the tree again is trivial.
>
> Cheers,
>
> Alasdair
>
>
> On 12 Apr 2012, at 22:03, Bayard G. Bell wrote:
>
>> Unless I hear any compelling objection, I'm going through with this this
>> weekend.
>>
>> On Tue, 2012-04-10 at 18:51 +0100, Bayard G. Bell wrote:
>>> In the course of fulfilment of my request for git mirroring, I've
>>> learned that we have a slight problem in our history: someone forgot to
>>> put a space between their name and the angle brackets surrounding their
>>> e-mail address. There are two ways to fix this: one is to ask github to
>>> disable validation of this data, the other is to fix the history, which
>>> is a destructive change.
>>>
>>> Since we're just getting on our feet, I'm inclined to make two
>>> substantial clean-ups in the history, one is to fix these commit
>>> records, and the other is to remove backed out changesets so they don't
>>> show up in annotations (which seems reasonable, given that the net
>>> effect is that no change happened, which to my mind shouldn't have two
>>> records against it for most repository contents).
>>>
>>> That means everyone using illumos-userland will need to re-clone for
>>> both mercurial and git. I know it's ugly, but I think this is pretty
>>> much the last point at which we can bite the bullet and clean this up
>>> properly--the other option is a workaround, whereas this is a painful
>>> fix. On the plus side, we'll finally have mirrors of the canonical
>>> available as illumos/illumos-userland.
>>>
>>> Cheers,
>>> Bayard