bzr split feature idea

Sat Dec 13 17:27:02 GMT 2008

Howdy folks,

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 
files.
We have come to a realization that alot more people could participate in 
the project, 
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 
split function.
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:

original:
/
/bin
/bin/file.ksh
/bin/another.ksh
/etc
/etc/config.txt
/lib
/lib/somelib
/sec
/sec/sensitive.txt

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 
the /sec
What I would like to do is rip out the /sec from the tree so I would have 
two separate branches:

original-without-sec:
/
/bin
/bin/file.ksh
/bin/another.ksh
/etc
/etc/config.txt
/lib
/lib/somelib

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 
/sec tree.

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.

split-off-branch:
/
/sec
/sec/sensitive.txt

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 
to it.

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.

np

-----------------------------------------
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
and affiliates.

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...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20081213/5d58938c/attachment-0001.htm 