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

[John Arbash Meinel]

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

Aaron Bentley wrote:
| 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

IMO that is a bug in looms, and incompleteness in our fetch api (it should
accept several revisions to copy without having to call fetch multiple times.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH/ghvJdeBCYSNAAMRAlunAJ9s3E6qI0dBmeLCYnBM2qCCJYEI1wCgvB29
KD5cUho6wGxJDt2MeIGLeRs=
=Ihf5
-----END PGP SIGNATURE-----