[lkml]   [2005]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BK] cvs export

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?


> 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?


> 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 ;-).

64 bytes from 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:10    [W:0.050 / U:0.816 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site