bzr split feature idea
norris.x.pouhovitch at jpmchase.com
norris.x.pouhovitch at jpmchase.com
Sat Dec 13 17:27:02 GMT 2008
I have run into a situation where I cannot find an easy way to resolve it
with present bzr implementation.
And I have some ideas conceptualy how to approach it, but, I do not think
they would be easy to implement,
and more importantly, I have no idea how usefull the feature would be long
term in the broader community.
We have an old branch that just a couple of people have been working on
very actively (for over a year now).
The branch has tens of merges and hundreds of revisions, and hundreds of
We have come to a realization that alot more people could participate in
however due to the unfortunate decision that was made early on - sensitive
data was stored in this projet along the way.
Luckily the sensitive data was isolated in it's own subdirectory, and so
it is easy to identify it.
Before we could release the project into the wider audience we must strip
the sensitive data out, which, is not that difficult todo using the bzr
However we would like to split the tree such that the split away branch
would have only the history that affected the downflow of it's children,
and no history for all the changes above it.
Here is a simplified sample tree:
Over the course of history say we have made 500 revisions in total (as a
result of merges, etc)
Out of those 500 revisions there were 450 that had changes unrelated to
What I would like to do is rip out the /sec from the tree so I would have
two separate branches:
Original project would now contain only those commits that affected any of
the files that were never part of the /sec subdirectory.
Those commits which were mixed and had some files part of /sec and other
files that were not part of /sec should still show up,
however references to the affected /src files should be removed, and it
should be impossible to export /sec related files
from the remaining original-without-sec branch. However it should be
possible to export any other revision of files that were never part of
The splif off project, could contain either all of the revisions (as it
does now), or depending on some command line flag,
only those revisions that affect the split off files only, and.... those
commits which were mixed, would have the references
to the previous branch files stripped out, but would retain the commits.
Doing this would produce some weird results, such that the revision
numbers would not be sequential at all.
The original branch may be left with revisions: 1,2,3,6,7,10 and so forth
And the split off branch either with all the revisions or with revisions
1,4,5,8,9,10 and so forth
(let's imagine that 1 and 10 were overlapping commits, so are present in
both, but only owned files could be exported from them)
At the end of the whole operation we would have two top level branches,
that still contain the history affecting it's members,
but, would not contain any references to the riped out subdirectories.
Without this functionality, we still can perform our split.
However, it would look somewhat different, and the results would not be
quite what is wanted.
We could split the /sec off into it's own branch, which would contain all
the previous history of the whole original branch,
and the limited audience which has the propper clearance could have access
And then we could start a brand new branch with the remaining working tree
contents. The very first commit would indicate that
any previous changes are now stored in a different repository and are
accessible only to the limited audience which has the propper
clearance to access the secure information which is still married to the
project in the history. This obviously would make it quite
inconvenient for the new project members (which do not have the propper
clearance and should not be able to access the secure contents)
to analyze the code history and gain deeper understanding of how did we
get to where we are.
Thank you guys in advance for your time digesting our pains.
Any further ideas or thoughts will be very much appreciated.
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bazaar