lkml.org 
[lkml]   [2005]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [BK] cvs export
    Hi!

    On Tue 01-03-05 17:14:19, Larry McVoy wrote:
    > A while back someone complained about the CVS exporter because it
    > sometimes groups a pile of BK changesets into one commit. That's true,
    > it does.
    >
    > I've been running tests over the BK tree and I think we can do better.
    > Here's the scoop: when we do an export we are going from a very bushy
    > graph structure to a linear graph structure. The BK graph structure
    > represents what happened in all the BK repos that ever came together,
    > the CVS graph structure is more like what would happen if all the work had
    > been done in CVS. What that means in practice is that the linearization
    > sometimes results in a single CVS commit which has multiple changesets
    > in it. Pavel or someone complained that the problem with that is that
    > if you are looking for a bug and you are searching through commits, that
    > works fine *unless* your bug happens to be in one of the commits which
    > is really a pile of changesets. Is that accurate Pavel/Andrea/Roman/etc?

    Yes.

    > In the last flamefest about BK there was all this fuss that there wasn't
    > enough info in the CVS export and I think that the problem described
    > above is the basis for 99% (or maybe 100%) of the flameage. Is that
    > also accurate?

    No comment -- I'm not sure how to measure flamage.

    > Which leads us back to the problem. If you narrow things down but where
    > you land is one of the clustered commits which has many changesets in it
    > then you are stuck with having to wade through a big pile of diffs to
    > find the bug, those diffs consisting of multiple patches. Sound right
    > to you Pavel/Andrea/Roman/etc?

    Yup.

    > When we do the export we do a couple of things to make things pleasant
    > for you. We make sure that the timestamps on all the files in the
    > same commit are the same, that makes timestamp based tools work.
    > We also shove a comment into each file's history that looks like so:
    > (Logical change 1.12345) so that tools that try and group things based
    > on comments can work.

    Seems nice. Notice that I'm not sure when next bug that will require binary search
    will pop up, so it may take a while before we'll actually know if it helped.

    > It's that second feature that I think we can use to solve the problem,
    > we're finally getting to the idea. If we have a commit that is really 200
    > patches which touch 400 files then we can do better. Suppose that the
    > files in the patches are disjoint, i.e., each patch touches a different
    > set of files, there is no overlap. If that's true then we could change
    > the comment to (Logical change 1.12345._PATCH). It's still all one CVS
    > commit but if you need to go working through that commit to get at the
    > individual patches you could, right?

    > One problem is that the set of files in patches may not be disjoint,
    > the same file may participate in multiple patches. I think we can handle
    > that in the following way, we put multiple comments, one for each patch,
    > so you'd see
    >
    > (Logical change 1.12345.5)
    > (Logical change 1.12345.11)
    > (Logical change 1.12345.79)
    >
    > That's not a perfect answer because now that file participates in
    > multiple patches and if it's the one that has the problem you'll have
    > to wade through the diffs for that file for that commit. But that's an
    > extreme corner case as far as I can tell (I have faith I'll be "educated"
    > if I'm wrong about that).

    Its certainly better than current situation. Next nasty ACPI problem will tell ;-).

    Pavel
    --
    64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms

    -
    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.036 / U:1.824 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site