Followup to: <[email protected]>
By author: Jeff Garzik <[email protected]>
In newsgroup: linux.dev.kernel
>
> You're missing the point:
>
> A BK exporter is useful. A BK clone is not.
>
I disagree. A BK clone would almost certainly be highly useful. The
fact that it would happen to be compatible with one particular
proprietary tool released by one particular company doesn't change
that fact one iota; in fact, some people might find value in using the
proprietary tool for whatever reason (snazzy GUI, keeping the suits
happy, who knows...)
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: cris ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Jeff Garzik <[email protected]>
> In newsgroup: linux.dev.kernel
>
>>You're missing the point:
>>
>>A BK exporter is useful. A BK clone is not.
>>
>
>
> I disagree. A BK clone would almost certainly be highly useful. The
> fact that it would happen to be compatible with one particular
> proprietary tool released by one particular company doesn't change
> that fact one iota; in fact, some people might find value in using the
> proprietary tool for whatever reason (snazzy GUI, keeping the suits
> happy, who knows...)
While people would certainly use it, I can't help but think that a BK
clone would damage other open source SCM efforts. I call this the
"SourceForge Syndrome":
Q. I found a problem/bug/annoyance, how do I solve it?
A. Clearly, a brand new sourceforge project is called for.
My counter-question is, why not improve an _existing_ open source SCM to
read and write BitKeeper files? Why do we need yet another brand new
project?
AFAICS, a BK clone would just further divide resources and mindshare. I
personally _want_ an open source SCM that is as good as, or better, than
BitKeeper. The open source world needs that, and BitKeeper needs the
competition. A BK clone may work with BitKeeper files, but I don't see
it ever being as good as BK, because it will always be playing catch-up.
Jeff
On Sun, Mar 02, 2003 at 12:12:58PM -0500, Jeff Garzik wrote:
> My counter-question is, why not improve an _existing_ open source SCM to
> read and write BitKeeper files? Why do we need yet another brand new
> project?
Or improve BK to export and import on demand of an existing open source SCM.
I'm a little confused about the on-disk format
is it SCCS and the problem is that CSSC doesn't recognise everything that
the latest SCCS does so a patch is needed for CSSC or does it differ
slightly from SCCS?
Larry has mentioned that there were things they changed from the base SCCS
format that they started with, but he indicated that they had fed patches
to SCCS to use the new info.
I'm trying to figure out if the problem is CSSC not being as compatible as
it would like to be or is larry not getting the changes he is proposing
into SCCS, or are there other problems.
David Lang
On Mon, 3 Mar 2003, nickn wrote:
> Date: Mon, 3 Mar 2003 00:47:28 +0000
> From: nickn <[email protected]>
> To: Jeff Garzik <[email protected]>
> Cc: H. Peter Anvin <[email protected]>, [email protected]
> Subject: Re: BitBucket: GPL-ed *notrademarkhere* clone
>
> On Sun, Mar 02, 2003 at 12:12:58PM -0500, Jeff Garzik wrote:
> > My counter-question is, why not improve an _existing_ open source SCM to
> > read and write BitKeeper files? Why do we need yet another brand new
> > project?
>
> Or improve BK to export and import on demand of an existing open source SCM.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
David Lang wrote:
> I'm a little confused about the on-disk format
>
> is it SCCS and the problem is that CSSC doesn't recognise everything that
> the latest SCCS does so a patch is needed for CSSC or does it differ
> slightly from SCCS?
CSSC can read the sfiles with the patch posted to lkml, but it cannot
read the BitKeeper-specific files such as the all-important ChangeSet
file. ChangeSet is required to build the DAG that weaves all the sfiles
together into the proper order.
Jeff
nickn wrote:
> On Sun, Mar 02, 2003 at 12:12:58PM -0500, Jeff Garzik wrote:
>
>>My counter-question is, why not improve an _existing_ open source SCM to
>>read and write BitKeeper files? Why do we need yet another brand new
>>project?
>
>
> Or improve BK to export and import on demand of an existing open source SCM.
That may be possible with OpenCM, but it's a bit of a stretch for the
other existing SCMs. Regardless, if BK can export metadata to an open
format (such as a defined XML spec), then the SCM interchange
possibilities are only limited by a programmer's time and imagination.
Jeff
On Sun, Mar 02, 2003 at 12:12:58PM -0500, Jeff Garzik wrote:
> My counter-question is, why not improve an _existing_ open source SCM to
> read and write BitKeeper files? Why do we need yet another brand new
> project?
Normally, I'd agree with you Jeff. However, none of the current
open source SCM systems are architected in a way that can operate like
BK.
I've been using subversion for a while now. It pretty much
fixes all the problems that CVS had, AS LONG AS you accept the CVS style
of version control. That style doesn't work for non-central work like
the kernel.
The one thing BK does that makes it worthwhile is the three-way
merge. This (and the resulting DAG) make handling code from Alan, from
Linus, from Andrew, and from everyone else possible. With CVS,
subversion, or any other SCM I've worked with, you have to hand merge
anything past the first patch. Ugh.
This requires architecture, and (AFAIK) BitBucket is the first
try at it. Compatibility with the proprietary tool that does it already
is a good thing.
Joel
--
"Can any of you seriously say the Bill of Rights could get through
Congress today? It wouldn't even get out of committee."
- F. Lee Bailey
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: [email protected]
Phone: (650) 506-8127
Jeff Garzik <[email protected]> said:
[...]
> That may be possible with OpenCM, but it's a bit of a stretch for the
> other existing SCMs. Regardless, if BK can export metadata to an open
> format (such as a defined XML spec),
Like something quite as obscure as unidiff?
> then the SCM interchange
> possibilities are only limited by a programmer's time and imagination.
Then we are done ;-)
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Horst von Brand wrote:
> Jeff Garzik <[email protected]> said:
>
> [...]
>
>
>>That may be possible with OpenCM, but it's a bit of a stretch for the
>>other existing SCMs. Regardless, if BK can export metadata to an open
>>format (such as a defined XML spec),
>
> Like something quite as obscure as unidiff?
>
Unidiff isn't metadata. Jeff is talking about the metadata which gives
context to the unidiffs.
-hpa
On Mon, Mar 03, Joel Becker wrote:
> On Sun, Mar 02, 2003 at 12:12:58PM -0500, Jeff Garzik wrote:
> > My counter-question is, why not improve an _existing_ open source SCM to
> > read and write BitKeeper files? Why do we need yet another brand new
> > project?
>
> Normally, I'd agree with you Jeff. However, none of the current
> open source SCM systems are architected in a way that can operate like
> BK.
Ah, finally we got to the root of the "problem".
--
A: No.
Q: Should I include quotations after my reply?
Hi!
> While people would certainly use it, I can't help but think that a BK
> clone would damage other open source SCM efforts. I call this the
> "SourceForge Syndrome":
Where do I get pills for that one? :-)
> Q. I found a problem/bug/annoyance, how do I solve it?
> A. Clearly, a brand new sourceforge project is called for.
>
> My counter-question is, why not improve an _existing_ open source SCM
> to read and write BitKeeper files?
I of course thought about that (I'm not yet
hit *that* hard by sf syndrome :-), but:
a) I might extend cssc, but bitbucket is
naturally layer *over* cssc, and cssc
is GNU program (copyright assignment
needed) and is C++. I do not feel like
writing new code in C++, and I do not
like their codingstyle.
b) take something else, *merge cssc to
it*, then add my stuff. Ouch. svn is out
because of licensing, cvs is not powerfull
enough, and I do not like arch. (I did
not know abojt opencm, sorry). Ouch
and this would mean fork, anyway,
because developers of that project
would probably not be happy about
those copyrights (FSF!).
c) so new sf project is indeed way to go :-(.
I hope you understand now,
Pavel
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
Hi!
> The one thing BK does that makes it worthwhile is the three-way
> merge. This (and the resulting DAG) make handling code from Alan, from
> Linus, from Andrew, and from everyone else possible. With CVS,
> subversion, or any other SCM I've worked with, you have to hand merge
> anything past the first patch. Ugh.
What's so magical about 3way merge?
I thought it would be easy to do even
in CVS...
Pavel
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
Pavel Machek wrote:
>it*, then add my stuff. Ouch. svn is out
>because of licensing, cvs is not powerfull
>
Could you or somebody else explain this repeated claim that the
Subversion licensing is problematic?
I don't have anything to do with the project, but a quick perusal of the
license doesn't reveal any problems. It's basically an Apache/BSD
license (pasted below for your reading pleasure).
-Tupshin
------------Subversion copyright---------------
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. The end-user documentation included with the redistribution, if
any, must include the following acknowledgment: "This product includes
software developed by CollabNet (http://www.Collab.Net/)."
Alternately, this acknowledgment may appear in the software itself, if
and wherever such third-party acknowledgments normally appear.
4. The hosted project names must not be used to endorse or promote
products derived from this software without prior written
permission. For written permission, please contact [email protected].
5. Products derived from this software may not use the "Tigris" name
nor may "Tigris" appear in their names without prior written
permission of CollabNet.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL COLLABNET OR ITS CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This software consists of voluntary contributions made by many
individuals on behalf of CollabNet.
Hi!
> >it*, then add my stuff. Ouch. svn is out
> >because of licensing, cvs is not powerfull
> >
> Could you or somebody else explain this repeated claim that the
> Subversion licensing is problematic?
>
> I don't have anything to do with the project, but a quick perusal of the
> license doesn't reveal any problems. It's basically an Apache/BSD
> license (pasted below for your reading pleasure).
You snipped what you should not snip: I'd need to merge CSSC (GPL-ed)
and svn (BSD with advertising). I may not do that. svn license is
okay, but merging it with CSSC is not possible.
Pavel
--
Horseback riding is like software...
...vgf orggre jura vgf serr.