split
Talden
talden at gmail.com
Tue Apr 8 20:45:29 BST 2008
> 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
More information about the bazaar
mailing list