lkml.org 
[lkml]   [2005]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Linux Kernel Subversion Howto
Hi,

On Sun, 6 Feb 2005, Larry McVoy wrote:

> > $ find -name \*,v -a ! -path ./BitKeeper\* -a ! -name ChangeSet,v | xargs rlog | egrep '\(Logical change 1.[0-9]+\)' | wc -l
> > 187576
>
> Bzzt. You forgot all the intial deltas which are not marked with the
> logical change comment. And just to double check my logic I tried it
> with rlog (much slower but whatever):
>
> $ /tmp/linux-2.5-cvs find linux-2.5/ -name '*,v' |
> xargs rlog | grep 'total revisions' |
> awk 'BEGIN { n = 0 }; { n = n + $NF }; END { print n }'
> 237338
> $ /tmp/linux-2.5-cvs perl REVS
> files=22966 revs=237338
>
> Imagine that, the numbers match perfectly.

Bzzt. Larry, I will make this one very easy, so that even you can follow
it. Let's take a simple file:

$ rlog REPORTING-BUGS,v | grep 'total revisions'
total revisions: 3; selected revisions: 3
$ rlog REPORTING-BUGS,v | egrep '\(Logical change 1.[0-9]+\)'
(Logical change 1.31)
(Logical change 1.3)
Now please check http://linux.bkbits.net:8080/linux-2.6/hist/REPORTING-BUGS
and tell me which number is correct.

> It's always possible I've made a mistake but you really ought to check
> your work a little bit before making false claims. It's trivial to do
> what I did which is run the script over a single file and hand verify
> that it is correct.

Ditto.

> > [Questionable complaints that he isn't getting enough information]

I challenge you to quote a single complaint I did in this mail.
All I did was adding the missing facts, which you like to forget to
mention and giving anyone the necessary information to verify them.

> First, you can get all the granularity that you want from bkbits.net.
> Find the file you want, find the revision, and go backwards to the
> changeset. It takes you a few clicks to do that.

Once again our dear Larry tells only half the story. It's true that single
file changes (which are in bkcvs are only available to 85%) are completely
available via bkweb to 100%. The problem is again how all these changes
relate to each other (the 44% number for bkcvs).
To give everyone an idea what this means, let's take a bit more
complicated file like http://linux.bkbits.net:8080/linux-2.6/hist/MAINTAINERS
Now try to figure out what all the revisions saying "Auto merged" actually
merge. It's actually possible, but one has to use heuristics which can
fail, so while one can restore most of the history of a single file, it's
not reliable anymore as soon as the branching becomes more complex.
The real trouble starts if one wants to know how all these files relate to
each other. Right now the bk tree contains over 59000 snapshots of how the
kernel looked at a specific point. To restore these snapshots again one
must apply the changesets in the correct order (this is equally true for
the commit mails), IOW one must know the parent revisions of a changeset
to really restore the history and to not just look at a part of it, but
bkweb unfortunately doesn't provide this information in full. Within a
branch the patch order is of course obvious, but one must also know where
a branch starts and ends, which is unfortunately not as obvious as one
might think. E.g. SCCS files are limited to a single branch level and bk
inherited this, so a branch of 1.2.3.4 is not 1.2.3.4.1.1 but something
like 1.2.4.1.
Larry, so far I have only stated facts, which are easily verifiable, how
about you come up with some facts of your own to prove me wrong? If I'm
just "complaining" and all the information is out there, it should be easy
for you to do...

> Fourth, it is your choice to not use BitKeeper because you want to compete
> with the people who are helping you. It's not that unreasonable that
> you find yourself at something of a disadvantage because of that choice.
> And the disadvantage is very slight as has been shown. You can argue
> all you want about the amount of disadvantage but it is your choice that
> has placed you in that position.

Well, I'm not the one who claimed "We don't do lockins. Period."
I'm just trying to figure out what that means...

bye, Roman
-
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    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site