lkml.org 
[lkml]   [2003]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: RFC - tarball/patch server in BitKeeper
Date
On Sun, 14 Dec 2003 15:44:23 -0800, 
Larry McVoy <lm@bitmover.com> wrote:
>On Mon, Dec 15, 2003 at 10:05:03AM +1100, Keith Owens wrote:
>> On Sun, 14 Dec 2003 09:21:56 -0800,
>> Larry McVoy <lm@bitmover.com> wrote:
>> >I've prototyped an extension to BitKeeper that provides tarballs
>> >and patches. ...
>> >... You need to understand that this is all you get,
>> >we're not going to extend this so you can do anything but track the most
>> >recent sources accurately. No diffs. No getting anything but the most
>> >recent version. No revision history.
>>
>> Do we get the changelogs from each BK check in? Without the
>> changelogs, patches are going to be much less useful.
>
>You already get those, use BK/Web. It's all there and always has been.

Using update and BK/Web means manually reconciling two sets of data
which may have different time bases. If update has not been run for 23
days, the user has to look at "Changesets in the last four weeks" and
manually determine where in that log of 119 changesets (linux-2.5)
their last update was done before they know which changesets are in the
current update.

What about this, assuming it does not give away information that you
believe will be used for $SCM. Treat the BK changelog as a file, and
have update generate a patch from the last update for the changelog as
well as the project files.

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