Messages in this thread | | | From | Keith Owens <> | Subject | Re: A modest proposal -- We need a patch penguin | Date | Fri, 01 Feb 2002 12:37:15 +1100 |
| |
On Thu, 31 Jan 2002 17:04:28 -0800, Larry McVoy <lm@bitmover.com> wrote: >On Fri, Feb 01, 2002 at 11:29:58AM +1100, Keith Owens wrote: >> That sounds almost like what I was looking for, with two differences. >> >> (1) Implement the collapsed set so bk records that it is equivalent to >> the individual patchsets. Only record that information in my tree. >> I need the detailed history of what changes went into the collapsed >> set, nobody else does. >> >> (2) Somebody else creates a change against the collapsed set and I pull >> that change. bk notices that the change is again a collapsed set >> for which I have local detail. The external change becomes a >> branch off the last detailed patch in the collapsed set. > >This is certainly possible to do. However, unless you are willing to fund >this development, we aren't going to do it. We will pick up the costs of >making changes that you want if and only if we have commercial customers >who want (or are likely to want) the same thing. Nothing personal, it's >a business and we make tradeoffs like that all the time.
Understood.
>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 >be used. > >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 change.
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |