From: Keith Owens <kaos@ocs.com.au>
To: Larry McVoy <lm@bitmover.com>
Cc: linux-kernel@vger.kernel.org, bitkeeper-users@bitmover.com
Subject: Re: RFC - tarball/patch server in BitKeeper
Date: Mon, 15 Dec 2003 11:25:11 +1100 [thread overview]
Message-ID: <3034.1071447911@kao2.melbourne.sgi.com> (raw)
In-Reply-To: Your message of "Sun, 14 Dec 2003 15:44:23 -0800." <20031214234423.GB15850@work.bitmover.com>
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.
next prev parent reply other threads:[~2003-12-15 0:25 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-14 17:21 RFC - tarball/patch server in BitKeeper Larry McVoy
2003-12-14 23:05 ` Keith Owens
2003-12-14 23:44 ` Larry McVoy
2003-12-15 0:25 ` Keith Owens [this message]
2003-12-15 3:47 ` Larry McVoy
2003-12-14 23:17 ` Tupshin Harper
2003-12-14 23:43 ` Larry McVoy
2003-12-15 0:19 ` Tupshin Harper
2003-12-15 3:46 ` Larry McVoy
2003-12-15 6:07 ` Tupshin Harper
2003-12-15 16:02 ` Larry McVoy
2003-12-15 19:52 ` Tupshin Harper
2003-12-15 6:31 ` Martin J. Bligh
2003-12-15 12:11 ` Sergey Vlasov
2003-12-15 13:27 ` Ben Collins
2003-12-15 16:24 ` Sergey Vlasov
2003-12-15 16:32 ` Larry McVoy
2003-12-15 18:31 ` Andrea Arcangeli
2003-12-15 18:58 ` Larry McVoy
2003-12-15 19:40 ` Andrea Arcangeli
2003-12-15 21:44 ` Larry McVoy
2003-12-15 22:02 ` Andrea Arcangeli
2003-12-15 22:14 ` Larry McVoy
2003-12-15 22:44 ` Tupshin Harper
2003-12-15 23:13 ` Andrea Arcangeli
2003-12-15 22:36 ` Tupshin Harper
2003-12-15 22:46 ` Larry McVoy
2003-12-15 23:08 ` Tupshin Harper
2003-12-17 4:47 ` Matthew D. Pitts
2003-12-15 15:42 ` Larry McVoy
2003-12-15 15:55 ` Martin J. Bligh
2003-12-15 23:18 ` Chris Frey
2003-12-21 20:02 ` Pavel Machek
2003-12-21 20:46 ` John Bradford
2003-12-24 1:49 ` Larry McVoy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3034.1071447911@kao2.melbourne.sgi.com \
--to=kaos@ocs.com.au \
--cc=bitkeeper-users@bitmover.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lm@bitmover.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox