That's nice. Are you implying that everyone else is just doing RCS?
BK certainly does more than that, you get full changesets, complete
reproducability in a distributed environment, etc. So what's your
point?
> > Cool. So explain to us how Aegis handles the following:
> >
> > . disconnected operation with updates to all repositories
>
> You have a local copy, of course (just like folks do now, just like
> any other tool requires). Except, instead of hammering on it
> directly, you work in a change set.
What if I don't want to do that?
> > . undo - including things you don't do but incorporated
>
> Aegis doesn't have uncomditional commit/incorporate.
Pity for it. BK does. BK is a strict superset of Aegis in this respect.
With the difference being that we don't encode our policy into the
mechanism. Even though I happen to agree, in principle, with the policies
which Aegis enforces, that doesn't mean that they are right. Sticking
your meethodology in my face isn't likely to get me to use your system.
I want to make that choice for myself. Which is what BK lets you do.
> However, if
> you did decide to incorporate a "foreign" change set, or any other
> change set for that matter, and later wish to remove it, you create
> another change set, add the historical versions of the relevant
> file (i.e. before the unwanted change) and proceed as normal.
> Pretty boring stuff, really, same as all systems do.
Bzzt. It's a one line command in BK. Once again BK is a superset.
We can do the anti-changeset as you describe (and generate it
automatically, without adding anything to the size of the repository,
try that in RCS), or we can just make the changeset completely
disappear. Your choice.
> Note: Aegis *doesn't* magically whisk the change set out of the
> sequence, and reproject the repository. Repository transactions,
> like any database transaction, are NOT COMMUTATIVE in the general
> case. Aegis requires that all changes be validated, including
> undoing.
How nice for it. Wonderful in theory, horrible in practice. Once
again, sticking your methodology in my face.
Look, I have strong opinions too, opinions which are quite similar
to yours, Peter. But they are OPINIONS, not facts. We would both
like to believe that our way is the only correct way but we are
bothh full of shit. The world likes making up its own mind and a
tool which tries and be Daddy just isn't going to be accepted.
Especially by a crowd of people who for 8 years have managed to
do better than anyone in the history of computing using nothing
but tar. Kinda makes your methodology look a little silly by
comparison. Not wrong, just silly.
> > . multiple views, each of which include some subset of the others
>
> Each branch is "overlayed" on its parent branches. Files which
> are not modified by a branch are inherited from the parent branch,
> so if the parent branch changes, these changes "propagate" into
> the child. Various "insulation" schemes are possible on top of
> this basic mechanism.
Great. I have 1000 different branches, with 10,000 different changes.
I want to include some subset all changes from all branches in each
branch. How big is your revision history file? About 9,000 times
bigger than a BK file doing the same thing.
> > . compressed repositories
>
> The history tool is decoupled from Aegis. You can use whatever
> you wish. You can put a compressing wrapper shell script around
> RCS or SCCS if that is what you need. Aegis doesn't care, just so
> long as it can get the info back out again.
That's nice. It's also completely unreasonable. There are a number
of operations which have to plow through the metadata to do anything.
BK takes the approach of gzipping the non-meta data portion, while
leaving the metadata uncompressed. We get space savings and performance.
Gzipping the whole mess would be completely unreasonable for performance.
> There is an option, but it defaults to off, to compress Aegis'
> database files.
Nifty. Database files next to my repository files. What happens
when the DB gets corrupted?
> > . disk and/or file systems which corrupt the underlying files
>
> This is Larry's hobby horse. Aegis leaves operating system
> reponsibilities with the operating system. If your file system
> corrupts files, it has a BUG. Fix the OS, not all of the apps
> which -> depend <- on it. Sheesh.
It is a _fact_ that disks go bad and that file systems can corrupt
files. It is a _fact_ that billons of dollars of IP are put into
source control systems. And you think it is OK to just say "fix
the OS"? Bully for you but hell would freeze over before I'd let
you near my source.
Any source system which doesn't detect corruption immediately should
be tossed out the door. My personal feeling is that BK should be
more paranoid about this, not less.
> > . low bandwidth links
>
> Aegis decouples the transmition of the change set. You can use
> just about anything: email, ftp, web, sneaker not, just tell Aegis
> the command you want executed. BUT: that means Aegis doesn't know
> or care about the bandwidth of your link. It does, by default,
> gzip|mpack the change set, but you can turn either or both off
> (e.g. no mpack when I'm distributing using FTP.)
Nicely side stepping the question. If I have a changeset which has
N bytes of data changed, where N is measured as "diff -n | wc -c"
of the changeset, how much data does aegis send across the wire to
propogate that change?
And how much data was sent across the wire to figure out what to
send?
And while we're at it, suppose I have 2 repositories with 100,000
files in them. Suppose that they are uptodate. How long does it
take Aegis to figure that out?
> 2. No UNCONDITIONAL commits. Ever.
Jeeze. BK is quite happy to stick whatever you ask it into a
repository. The reason that it is happy to do so is because it
can undo that change with a single command.
> No way any incoming patch from IDontKnowYou is going into my
> repository without any preconditions! (Really simple preconditions
> like "the repository still builds" and "the repository still
> tests out OK")
And what, pray tell, is wrong with optimizing for the common case, which
is the changeset is just fine? It seems to me that you are making your
users do extra work that they don't need to do.
> 3. Aegis is open source. Bitmover is ajar source.
BitKeeper is as open as it can be. You get source, you get to wack
it and redistribute it for free. The license isn't as open as you
want but that's because we need to make money in order to support BK
and move on to developing the next generation of tools: bug tracking,
binary file revisioning, project management, etc. It's wonderful that
your tool is open source, but I'm a little concerned with your roadmap.
I'd really like to know when it will solve the same set of problems BK
can solve (making it a clearly better product), and when you are going
to integrate bug tracking in, mailing list and web server support, etc.
And how are you going to pay for all that development?
These are serious questions. If you have a good set of answers, I'd just
love to hear them. But if you don't, if you aren't going to solve 100%
of the problem and give people the assurances that they need that Peter,
Inc. is going to stand behind Aegis for the next 20 years, then why are
you here? Don't you think it is a little unfair to get people interested
in infrastructure that you have no intention of supporting at commercial
levels? What happens when you get interested in something else? I watch
the Aegis source tree and I'm not seeing this huge wave of development
coming in from the free software crowd, so that means I need to depend
on you. Are you going to make this work on all platforms? Where's the
NT, Windows/98, Mac, etc., ports? Etc.
----- Larry McVoy lm@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.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/