lkml.org 
[lkml]   [2002]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: A modest proposal -- We need a patch penguin
    Date
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:16    [W:7.164 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site