Andrew and I thought it might be an interesting experiment to move rsync to using BitKeeper rather than CVS for source code control. For a project with rsync's size and activity CVS is actually fine, but it would be a nice "toe in the water" with BitKeeper to get some practical experience before possibly using it on larger projects. BK is moderately well-proven on open source projects including MySQL, the PowerPC Linux kernel port, and the ext2 filesystem, although of course it's not nearly so widely used as CVS. You can find a lot more information about the differences here: http://bitkeeper.com/4.1.1.html BitKeeper is not strictly Open Source, but arguably good enough. The proposed plan is to convert the existing repository, retaining all history, some time in December. At this point CVS will become read-only and retain historical versions. Developers with write access will be able to modify the code using BitKeeper-over-ssh, similarly to the way we use cvs-over-ssh presently. (At the moment I think this only really applies to Dave, Andrew and myself.) This will mean installing a BitKeeper client on your development machine. I found it took a couple of hours to get to know it -- most of the concepts about code control carry across quite directly from CVS. Binaries are available for many platforms, and source is available to cover the others. I think BK is sufficiently promising to justify the investment. Non-core developers and other users will be able to access rsync source as at present by - downloading release or release-candidate tarballs - rsync from an unpacked source tree In addition, we will offer anonymous read/only BitKeeper access, and BK/web corresponding to CVSweb. We may maintain an anonymous CVS read-only tree based on the BK tree if there is sufficient demand. As at present, we welcome contributions in diff form from interested developers in the community. In addition to plain diffs, if we move to BK we will also accept diffs with BK metadata annotations, which will be a slightly more systematic way to manage them. I will probably set up a r/o BK copy of the tree sometime in December to let people try it out. If we decide to switch there will be a flag day at which CVS becomes readonly and BK writable. If it turns out to be a fiasco we can switch back to CVS. I don't think the change will be too disruptive, but of course I wanted to consult before moving. Please send any comments to me or to the list, whether they be "it's great, let's do it", or "I don't have time to switch." (If you need to flame about the licence then please send it direct to me rather than burning up the list.) -- Martin
If you're serious about not using CVS (and I've used it, I understand why you might be :), may I suggest Perforce? It's a commercial product but it is free for use on open-source projects. The only complication would be you'd need to find a server to host it. I can say definitively that it ROCKS. TK> -----Original Message----- > From: Martin Pool [mailto:mbp@samba.org] > Sent: Thursday, December 06, 2001 1:19 AM > To: rsync@lists.samba.org > Cc: tridge@samba.org; Dave Dykstra > Subject: move rsync development tree to BitKeeper? > > > Andrew and I thought it might be an interesting experiment to move > rsync to using BitKeeper rather than CVS for source code control.
> You can find a lot more information about the differences here: > > http://bitkeeper.com/4.1.1.html > > BitKeeper is not strictly Open Source, but arguably good enough.I guess "arguably" is if you don't mind having all your metadata logged to an open logging server?> The proposed plan is to convert the existing repository, retaining all > history, some time in December. At this point CVS will become > read-only and retain historical versions.I'm curious at the driving force here? You talk about switching, but don't really mention much about why - other than to get feet wet before using it for other projects. So is it really the other projects that have specific needs? Is there specific functionality lacking in CVS that is trying to be fixed? At least for me, CVS is more convenient since it works will all the open projects I use (and yeah, is easier in terms of licensing). I don't have strong objections to a change, but as one user who does tend to track the source tree and not just releases, I definitely would prefer to continue to see (as you did suggest) alternative access to the current source tree (even if only daily snapshots), since at least for me rsync would be the only BK project I'd care about - it's not clear I'd want to bother with the client. -- David /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/
Martin Pool
2002-Jan-03 18:52 UTC
rsync+ tidyup (was Re: move rsync development tree to BitKeeper?)
On 6 Dec 2001, Jos Backus <josb@cncdsl.com> wrote:> I will also pound a little bit more on the rsync+ bits. Two more small nits: > > rsync.1: -f, --read-batch=FILE read batch file > rsync.yo: -f, --read-batch=FILE read batch file > > Here, FILE should be EXT, as it specifies the extension for the > batch files.> > Another thought: maybe we should reserve -f and -F for something else and just > stick with the long options? What do you think?That sounds like a good idea, as long as not too many people have started using them already. -- Martin The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://www.linux.org.au/conf
Jos Backus
2002-Jan-04 05:27 UTC
rsync+ tidyup (was Re: move rsync development tree to BitKeeper?)
On Thu, Jan 03, 2002 at 06:52:08PM +1100, Martin Pool wrote:> > Another thought: maybe we should reserve -f and -F for something else and > > just stick with the long options? What do you think? > > That sounds like a good idea, as long as not too many people have started > using them already.I seriously doubt anyone is using the batch feature because without the last patch I sent you it simply does not work :-) -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer;