Arador <[email protected]> wrote:
>Why to waste time trying to clone a
>tool such as bitkeeper? Why not to support things like subversion?
"Why" depends on one's priorities.
Some of us the linux-kernel crowd are interested in being able
to interface with the bitkeeper-using kernel developers a bit more
efficiently. The developers currently using bitkeeper started using
it when these other systems were already available, so I doubt that
improving another free version control system will do more for free
software adoption than providing BK compatability (I don't know if
that is a priority for you).
Note that Subversion, in particular, is GPL incompatible and
uses its own underlying repository format that isn't particularly
compatible with anything else and required a web server plus some
minor web server extension when last I checked. As I previously
mentioned, Bitkeeper is based on sccs for which a GPL-compatible clone
exists: cssc, and sccs format is used in a lot of other places as
well. So the result of cloning the "uber-cvs" in bitkeeper might
actually have more applicability than trying to extract the same layer
from subversion, even though Subversion is freer than BitKeeper.
Different people have different priorities or order them
differently. If you contribute to aegis, prcs, or even Subversion, I
think that's great. If you produce a separate GPL compatible
"uber-CVS" layer that way, I would be interested in hearing about it.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
On Sat, Mar 01, 2003 at 06:23:21PM -0800, Adam J. Richter wrote:
> Note that Subversion, in particular, is GPL incompatible and
http://subversion.tigris.org/project_license.html
I don't see anything particularly GPL-incompatible in there; looks pretty
much like a BSD-style license to me. Something that precludes SVN's use
by GPL'd projects, or precludes integration with GPL'd projects, is
something I'm sure CollabNet and the developers on the mailing list would
love to know about (along with all the Apache folks, since it's really
their license), considering that there's already at least on GPL'd
front-end for Subversion (gsvn), and plenty of GPL projects being hosted
in Subversion repositories.
(Not meant as a flame, please don't take it as such. I'd really like to
know where the Apache/Subversion license is "GPL-incompatible".)
> uses its own underlying repository format that isn't particularly
> compatible with anything else
Lacking an on-disk format that's actually useful for storing more
information than files and diffs, they invented one. I don't blame them.
The fun part, of course, is that svn is architected such that bolting up
to another repository storage system (say, an RDBMS, or even, horrors, a
bitkeeper-compatible SCCS derivative) is really just a matter of writing
the code (with a few caveats, obviously, but that's the basic idea).
"svnadmin dump" will provide a dumpfile of the repository, which could
be translated into another format, if that were desirable. Again, just a
simple matter of coding. ;-)
> and required a web server plus some
> minor web server extension when last I checked.
Not everyone is aware of this, but there's a new access method for svn
repositories that works with SSH, or as a standalone pserver-like scheme,
called "ra_svn". Translation: you no longer need Apache 2.0 and mod_dav
to access a Subversion repository; you just don't get some of the cool
features that using Apache gives you (such as all the access controls,
the availability of the repository via DAV and through a normal web
browser, etc).
This came about only a few milestones back, so it's not surprising that
everyone hasn't seen it yet. :-)
--
Edward S. Marshall <[email protected]>
http://esm.logic.net/
Felix qui potuit rerum cognoscere causas.
On Monday 03 March 2003 16:26, Edward S. Marshall wrote:
> On Sat, Mar 01, 2003 at 06:23:21PM -0800, Adam J. Richter wrote:
> >
> > [Subversion] uses its own underlying repository format that isn't
> > particularly compatible with anything else
>
> Lacking an on-disk format that's actually useful for storing more
> information than files and diffs, they invented one. I don't blame them.
There is plenty of justification all right. Besides adding metadata
versioning, they built it around an optimal binary-dff algorithm borrowed
from Josh Macdonald's PRCS/Xdelta, so the version database is more compact
and efficient than you can achieve with a diff or pure SCCS-based design.
> The fun part, of course, is that svn is architected such that bolting up
> to another repository storage system (say, an RDBMS, or even, horrors, a
> bitkeeper-compatible SCCS derivative) is really just a matter of writing
> the code (with a few caveats, obviously, but that's the basic idea).
For the long run, svn looks very good. I've seen many pot shots aimed at it,
but few survive scrutiny. The ones that do are:
- It's not quite here yet
- It's not Linus-compatible
The second one will take longer to solve than the first. In the meantime,
those who can't use Bitkeeper (that includes me, since I did some work on a
versioning filesystem, never mind annoying Larry) need some tools in order to
have any chance of keeping current with Linus and other maintainers. The
contributions of Andrea, Pavel and Rik in that area are extremely valuable,
and I thank them for it.
Regards,
Daniel.