split

[John Arbash Meinel]

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

Talden wrote:
|>  Daniel Oberhoff wrote:
|>  > Hmm, so there is no way to modify history?
|>
|>  Not in a decentralized VCS.  decentralized systems like this must be
|>  write-once at the logical level, or else you have an inconsistent system.
|>
|>  Aaron
|
| Though there's no reason why any holder of a branch can't make the
| decision to divorce themselves from their peers and make such changes
| - indeed sometimes there is an obligation to do so.
|
| This is sometimes a necessary evil for a central/official branch which
| needs to dramatically alter project structure or break-down to make
| itself more accessible to users (in this case by reducing the volume
| of content) for size or content reasons.
|
| Of course it requires breaking history completely as you would be
| doing the following in a destination partial copy:
|
|    * filtering content from existing revisions in the new branch.
|    * Removing revisions which have no paths to keep in this branch.
|
| You compromise the validity and appropriateness of commit messages in
| revisions kept and remove revisions from history altering revision
| numbers (and, AFAIK, though you don't have to change revision Ids you
| should do to differentiate revisions of this branch from it's origin
| which is no longer compatible) and any textual reference to the old
| rev-ids/rev-numbers is now incorrect.
|
| ALL consumers of the branch then need to branch/checkout again and any
| revisions they had not yet had merged/pulled into this peer are
| orphaned and need to be patched back in (possibly by hand).
|
| I think such a facility is an important tool for the Bazaar toolbox
| but the importance of absolutely minimising its use cannot be
| overstated.  Unless you have a true repo-size _problem_ and not just a
| _desire_ to reduce repo-size you should never undertake such a change.
|
| This discussion is analogous to the 'Obliterate' discussion on the
| Subversion lists where good arguments have been put forward for why it
| must be supported though discouraged - note that there are other
| reasons to do this than size (legal obligation, say removing
| encumbered code prior to exposing a code-base to an outside party).
|
| --
| Talden
|
|

It is called 'rebase' and is certainly possible. At the moment you need to do
some manual surgery to get things omitted, and I don't think rebase has been
taught how to handle changes to files that aren't present, but I believe it
would be possible.

It does change all the revision ids, because otherwise if ever the 2 forms met,
you would collapse space-time (or just get random errors, not sure which, I
don't want to be there when it happens :).

Anyway, most of the functionality is already in place, it would probably take me
a couple of days if I really wanted to put something in place to do the rest,
but my time is taken up with other things at the moment.

John
=:->

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

iD8DBQFH/KhHJdeBCYSNAAMRAt3hAJwMd3P3iFsATXZwkQ53NVa4S+VJLQCbBKCK
N5YIXUe6vApkQBuKa+en+aM=
=H7jZ
-----END PGP SIGNATURE-----