[MERGE] Implement reconfigure --standalone and --sharing

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> --shared sounds better and conforms to our general parameters better. (We
> generally use the past tense/adjective form.) However, it may be more
> confusing
> than --sharing.

I don't think it really does conform better, because the branch isn't
shared by anything.  It shares with the repository.

- --shared should mean "convert this into a shared repository", and I do
expect to implement that in the future.

I could live with --use-shared.

> Maybe --share-repository makes it clear that you are telling the branch
> to share
> the repository rather than any of the other permutations?

I think I'd prefer --use-shared.

> You are doing a whole-repository fetch, rather than a just-branch fetch
> here:

> I'm not sure that we are planning on preserving the whole-repository
> fetch api
> in the future. (Because we are trying to get rid of calls to things like
> '.all_revision_ids()').

I think that this sort of operation will always be with us, but should
see limited use (e.g. upgrade).

> If they were doing a branch+rename/rm stuff, then doing
> 'new_repo.fetch(self.repository, self.last_revision())' is valid. It is
> true
> that the fetch might miss some unreferenced revisions, but if there are
> unreferenced revisions in the branch, where could they have come from?

Looms.

I don't think people are expecting this operation to do garbage
collection, and since we are deleting the repository, I would rather err
on the side of caution.

> Maybe a
> pending merge in the working tree?
> 
> Anyway, I would *like* us to only to a partial fetch if possible (it will
> probably be considerably faster to not have to figure out all the revisions
> which are already present.)

I really don't think we should.  Losing revisions is a really unpleasant
kind of unintended consequence.

> We should at least test the behavior we end up chosing. By adding an
> unreferenced revision into the standalone branch repository, and then
> doing the
> reconfigure and assert whether or not the revision is in the result.

Can do.

> We should also go the other way. So if you turn a branch into a standalone
> branch, I think it really *should* filter at that point.

Well, this can break looms, but otherwise, I'm fine with the principle,
since the revisions would still exist in the shared repo.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH/Lmg0F+nu1YWqI0RArAcAJ9IJQ+JNDWQE94QWQYdyzRDKlLtDQCfSy0O
IMpel3TbfNn8yDz0Dme79Ms=
=Ci+P
-----END PGP SIGNATURE-----