Docs branch merge fallout

[Gervase Markham]

On 04/12/14 18:01, Gervase Markham wrote:
> Is it enough trouble that we want to back up and fix it, and deal with
> the fallout of fixing up the BZR and CVS mirrors manually, and deal with
> the fact that some people's checkouts may break (we'd have to manually
> fix those on landfill, for example)? We can recruit the help of some of
> our VCS experts who are here in Portland.

I talked to Mike Hommey. He says we could:

* Delete the offending commit and all commits after by moving the head
back to the last commit beforehand, and then pushing with git push -f.

* We would need to do some sort of manual fixup on any checkout which
wanted to push in the future. That's probably just the checkouts of the
core devs, at this stage.

* In terms of the bzr mirror, it's not clear what happens. How does our
bzr mirroring work? Can we delete the repo and start again, or would we
end up with new commit IDs? Can we do similar surgery? Mike doesn't know
because he's not too familiar with bzr.

* The checkouts on landfill are from bzr, and will have updated by now
to the version with the bad commits. Now might be a good time to switch
them over to using git...

Goodness knows how we'd fix the CVS repo... Perhaps it's time to abandon
it for trunk? :-)

The other option would be to start a new branch from before the merge,
and say "OK, trunk is now this new branch", and people would have to
switch over manually. We could call it "trunk" instead of "master". This
may have annoying fallout if the name "master" is the default in various
commands, I don't know. Mike thinks only "clone" does this.

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla