lkml.org 
[lkml]   [2005]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Linux Kernel Subversion Howto
    On Fri, Feb 04, 2005 at 10:39:22AM -0800, Larry McVoy wrote:

    > > > I suppose what we could do is stick the BK changeset key into the
    > > > delta history so that if you really wanted to get the BK level
    > > > granularity you could.
    > >
    > > This would be nice indeed and I think it would end up all whinning
    > > since using that, one could be able to get the full history from the
    > > bkcvs repository. But would you do that ?
    >
    > You get a commitment from the group of BK complainers that that is good
    > enough and we'll do it. It may take a while because in the current way
    > that BK stores metadata it would be prohibitively expensive. But we
    > want to change that anyway so we can prototype it on an internal tree
    > and see how well it works.
    >
    > If/when we do this we'll reexport the 2.4 and 2.5 histories from scratch
    > so you get the info going backwards in time.

    If we 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 (this being a GNU patch and a patch comment), this
    would be perfect for me. I can't speak for the 'group of BK
    complainers' but I can't see a *technical* reason why they would
    disagree with this.

    > So, do you think you can sign up the usual suspects to being happy with
    > this answer?

    I'll let them answer themselves.

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

    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.

    You said before that:
    > > I suppose what we could do is stick the BK changeset key into the
    > > delta history so that if you really wanted to get the BK level
    > > granularity you could.
    (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.

    What am I missing here ?

    Thanks,

    Stelian.
    --
    Stelian Pop <stelian@popies.net>
    -
    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:7.232 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site