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    [W:2.790 / U:0.192 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site