>Collapsing is relatively easy, it's tracking the same content in two
>different sets of deltas which is hard to get exactly correct. Certainly
>possible but I can visualize what it would take and it would be messy and
>disruptive to the source base for an obscure feature that is unlikely to
>Why don't you actually use BK for a while and see if you really think
>you need this feature. The fact that our customers aren't clamoring for
>it should tell you something. They do work as hard and on as much code
>(in many cases on the same code) as you do.
This is the way that I use PRCS now and it fits the diff/patch model
for distributing kernel code that most people are used to, while
reducing the concerns about information overload.
With PRCS I have branches galore with lots of little changes. The
outside world sees complete patch sets, not the individual changes.
When they send a patch back I work out which internal change it is
against and start a new branch against it. The downside with PRCS is
that the creation of the patch set and storing on an ftp site is a
manual process, as is identifying which internal change a patch
response is against and starting a new branch against the last internal
If bk could automate the creation and tracking of meta patchsets I
would convert tomorrow, the ability to automatically distribute changes
is what I miss in PRCS. But if using bk means that I cannot
automatically separate and track the internal and external patches then
there is no benefit to me in converting. If I have to clone a
repository to roll up internal patches into an external set and I
cannot automatically pull changes against the external set back into my
working repository then bk gives me no advantages.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/