lkml.org 
[lkml]   [2002]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: A modest proposal -- We need a patch penguin
    On Thu, Jan 31, 2002 at 02:50:31AM -0500, Rob Landley wrote:
    > On Thursday 31 January 2002 01:37 am, Larry McVoy wrote:
    >
    > > That said, I'm sympathetic to the "I make lotso changes and I want to
    > > collapse them into one big change" problem. It's certainly technically
    > > possible to make BK do that, but then you have to *know* that nobody
    > > else has a BK repo with your old detailed changes in it, or if they
    > > do, they won't ever try to push them back to you (or Linus or ...).
    >
    > No, bitkeeper simply has to know. :)
    >
    > Put in a node that says "this change collapses this range of other changes"
    > with a range or list of change IDs, and then when you do your next merge with
    > another tree, bitkeeper has the info it needs to avoid sucking in dupes. If
    > the node says you have that change already, you don't need to suck it in from
    > the other tree.
    >
    > > It's not an error if they do, it's just that BK will view them as
    > > different changes and automerge them right back into the history.
    > > So then you'll have both the collapsed version and the detailed version
    > > which puts you worse off than when you started.
    >
    > Just teach BK that the collapsed version includes everything in the detailed
    > version. (Even if that's not technically true, teaching one system to lie to
    > another is an important part of programming... :) Linus wanted checkpoint
    > functionality to limit backmerges, this seems sort of related-ish.
    > (Boundaries on change sets, merging change sets...)
    >
    > Is there an implementation reason why this is particularly hard, or some evil
    > nasty side effects to such an approach that we should know about?


    Can you detect the 'collapsed vs full version' thing, and force it to be
    a merge conflict? That, and working LOD support would probably get most
    of what I want (until I try the new version and find more stuff I want
    :P)

    --
    Troy Benjegerdes | master of mispeeling | 'da hozer' | hozer@drgw.net
    -----"If this message isn't misspelled, I didn't write it" -- Me -----
    "Why do musicians compose symphonies and poets write poems? They do it
    because life wouldn't have any meaning for them if they didn't. That's
    why I draw cartoons. It's my life." -- Charles Schulz
    -
    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:18    [W:8.314 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site