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
On 6 Dec 2001, Jos Backus [EMAIL PROTECTED] 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
Incidentally, here's an interesting BitKeeper demostration/tutorial:
http://www.bitkeeper.com/demo/
--
Martin
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
.
TK
-Original Message-
From: Martin Pool [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 06, 2001 1:19 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Dave Dykstra
Subject: move rsync development tree to BitKeeper?
Andrew and I thought it might be an interesting experiment
GNU Subversions is apparently now self-hosting (and is actually free,
instead of arguably free :-) If you're looking at perforce or
bitkeeper, though, also look at Accurev 3.0 (which is
free-for-free-software, in java, *fast* and has a better consistency
model...)
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
