Re: RFC - tarball/patch server in BitKeeper

Larry McVoy
2003-12-15T03:47:24Z

On Mon, Dec 15, 2003 at 11:25:11AM +1100, Keith Owens wrote:
> 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.

That would be what the BK2CVS export does. It's perfect for what you want,
use it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm