![]() | |||||||||||
Messages in this thread |
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 - 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 [from the cache] ©2003-2008 | |||||||||||