lkml.org 
[lkml]   [2005]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC] Linux Kernel Subversion Howto
    From
    > > So, do you think you can sign up the usual suspects to being happy with
    > > this answer?
    >
    > I'll let them answer themselves.

    You'll need to rally them to speak up or this is going nowhere. We
    can't afford to spend engineering dollars one unhappy person at a time
    to try and get you happy. We need concensus.

    > > And do you mind spelling out exactly what it is that you
    > > think is being offered so there is no confusion later?
    >
    > Informaly, exactly what I said before: Be able to find enough information
    > in the CVS tree which would allow anybody to trace back each change
    > to what was submitted by the author of the change (= patch + comment).

    Yup, seems reasonable.

    > How you can make this happen is another problem. The obvious way to
    > implement this is using CVS branches and merges but this could be
    > too much work for you.

    Yeah, that's insane, CVS just isn't up to the task. We know, we import
    history from CVS to BitKeeper all the time and it is very painful. We
    probably understand the impedence mismatch better than anyone and it is
    large.

    > (and know I agreed at the moment), but thinking again about this I'm not
    > sure anymore how "sticking the BK changeset key into the delta history"
    > gives us "BK level granularity". From what I understand (but you are the
    > SCM expert not me so I may be missing something) there is exactly
    > one delta per 'trunk' changeset, so if you have a file being modified
    > several times on a branch you will end with one single delta which is
    > the merge of the separate patches. I'm not sure how, by adding several
    > 'BK changeset keys' into the log entry of the merged delta you make
    > one able to resplit the delta later.

    First, you have to remember that BK is capturing 96% of the deltas made
    to files. Some of those deltas get clumped into one CVS commit because
    of the flattening of the graph structure. If each delta had the
    changeset key for the BK changeset to which it belonged you could
    split the coarse commit into the sub patches which happened on the
    collapsed branch. You wouldn't get 100% of the information but you'd
    have 96% of it in a way that could be used for debugging, which is what
    I suspect you are after.

    If that's not good enough then I'm not sure there is much point in
    continuing the conversation.
    --
    ---
    Larry McVoy lm at bitmover.com http://www.bitkeeper.com
    -
    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 14:10    [W:0.021 / U:32.848 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site