BitBucket: GPL-ed BitKeeper clone

BitBucket: GPL-ed BitKeeper clone

[Pavel Machek]

Hi!

I've created little project for read-only (for now ;-) bitkeeper
clone. It is available at www.sf.net/projects/bitbucket (no tar balls,
just get it fresh from CVS).

Part of readme follows.


Install CSSC from <http://cssc.sf.net/> (it is also available as
Debian package). You may need to apply cssc.diff.

Here you get following tools:

bcheckout_HEAD:
        extracts files from BK repository. You can get repository
        by rsync -zav --delete nl.linux.org::kernel/linux-2.5 .

bpull:
        pull new version of repository, compute differences from
        the last time and apply them to directory with *your*
        sources.

bdiff:
        compare two versions (specify versions from top-level
        s.ChangeSet)

To get a list of all changesets, do prs linux-2.5/SCCS/s.ChangeSet.

Enjoy, and help me make it usefull,
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: BitBucket: GPL-ed BitKeeper clone

[Larry McVoy]

BitKeeper is a trademark, please don't use the BitKeeper name when
describing BitBucket.  Thanks.

On Wed, Feb 26, 2003 at 09:02:12PM +0100, Pavel Machek wrote:
> Hi!
> 
> I've created little project for read-only (for now ;-) bitkeeper
> clone. It is available at www.sf.net/projects/bitbucket (no tar balls,
> just get it fresh from CVS).
> 
> Part of readme follows.
> 
> 
> Install CSSC from <http://cssc.sf.net/> (it is also available as
> Debian package). You may need to apply cssc.diff.
> 
> Here you get following tools:
> 
> bcheckout_HEAD:
>         extracts files from BK repository. You can get repository
>         by rsync -zav --delete nl.linux.org::kernel/linux-2.5 .
> 
> bpull:
>         pull new version of repository, compute differences from
>         the last time and apply them to directory with *your*
>         sources.
> 
> bdiff:
>         compare two versions (specify versions from top-level
>         s.ChangeSet)
> 
> To get a list of all changesets, do prs linux-2.5/SCCS/s.ChangeSet.
> 
> Enjoy, and help me make it usefull,
> 								Pavel
> -- 
> When do you have a heart between your knees?
> [Johanka's followup: and *two* hearts?]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BitBucket: GPL-ed BitKeeper clone

[Ben Collins]

On Sat, Mar 01, 2003 at 07:28:20AM -0800, Larry McVoy wrote:
> BitKeeper is a trademark, please don't use the BitKeeper name when
> describing BitBucket.  Thanks.

I think he's allowed to use the name so long as he only uses it to
describe what the purpose of the tool is and recognizes in the same
document who the holder of the trademark is. Just the same as someone
can write an article about Windows and Microsoft, or a software product
can claim that it runs under Windows or MacOS.


He's allowed to say "This tool allows you to access a BitKeeper
repository".



-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: BitBucket: GPL-ed BitKeeper clone

[Larry McVoy]

He's not allowed to say "BitBucket is a GPL-ed clone of BitKeeper"
because that implies that BitBucket does what BitKeeper does and nothing
could be farther from the truth.

How about we not turn this into a debate?  I politely requested that
people not confuse the world into thinking Product A is the same as
Product B, that's all I requested, it's a reasonable request, we don't
need to debate it.  If you feel the need to do so, go for it, but do so
knowing that my silence in no way means that I agree or disagree with you.

On Sat, Mar 01, 2003 at 11:02:22AM -0500, Ben Collins wrote:
> On Sat, Mar 01, 2003 at 07:28:20AM -0800, Larry McVoy wrote:
> > BitKeeper is a trademark, please don't use the BitKeeper name when
> > describing BitBucket.  Thanks.
> 
> I think he's allowed to use the name so long as he only uses it to
> describe what the purpose of the tool is and recognizes in the same
> document who the holder of the trademark is. Just the same as someone
> can write an article about Windows and Microsoft, or a software product
> can claim that it runs under Windows or MacOS.
> 
> 
> He's allowed to say "This tool allows you to access a BitKeeper
> repository".
> 
> 
> 
> -- 
> Debian     - http://www.debian.org/
> Linux 1394 - http://www.linux1394.org/
> Subversion - http://subversion.tigris.org/
> Deqo       - http://www.deqo.com/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: BitBucket: GPL-ed BitKeeper clone

[John Bradford]

> Something is wrong, I agree with Larry.

Errr, it's the first of March today, not the first of April.

John.

Re: BitBucket: GPL-ed BitKeeper clone

[Ben Collins]

On Sat, Mar 01, 2003 at 05:30:42PM +0000, Alan Cox wrote:
> On Sat, 2003-03-01 at 16:11, Larry McVoy wrote:
> > He's not allowed to say "BitBucket is a GPL-ed clone of BitKeeper"
> > because that implies that BitBucket does what BitKeeper does and nothing
> > could be farther from the truth.
> 
> Something is wrong, I agree with Larry.
> 
> He should instead say "A tool for accessing bitkeeper repositories" or
> "bitbucket compatible proprietary tools are available from .. " ;)

I can agree with that. At first though, he said not to use the name at
all, without regard to wording.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: BitBucket: GPL-ed BitKeeper clone

[Aaron Lehmann]

On Wed, Feb 26, 2003 at 09:02:12PM +0100, Pavel Machek wrote:
> It is available at www.sf.net/projects/bitbucket (no tar balls,
> just get it fresh from CVS).

It would be better if you stored it in BitKeeper just to piss Larry
off.

Re: BitBucket: GPL-ed BitKeeper clone

[Bernd Eckenfels]

In article <20030301170130.GJ9624@vitelus.com> you wrote:
> It would be better if you stored it in BitKeeper just to piss Larry
> off.

that would be a license violation :)

Greetings
Bernd
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

Re: BitBucket: GPL-ed BitKeeper clone

[Alan Cox]

On Sat, 2003-03-01 at 16:11, Larry McVoy wrote:
> He's not allowed to say "BitBucket is a GPL-ed clone of BitKeeper"
> because that implies that BitBucket does what BitKeeper does and nothing
> could be farther from the truth.

Something is wrong, I agree with Larry.

He should instead say "A tool for accessing bitkeeper repositories" or
"bitbucket compatible proprietary tools are available from .. " ;)

Re: BitBucket: GPL-ed KitBeeper clone

[Pavel Janík]

   From: Pavel Machek <pavel@ucw.cz>
   Date: Wed, 26 Feb 2003 21:02:12 +0100

Pavel,

   > I've created little project for read-only (for now ;-) kitbeeper
   > clone. It is available at www.sf.net/projects/bitbucket (no tar balls,
   > just get it fresh from CVS).

I think that it is waste of your valuable time to create clones of
proprietary software like KitBeeper (I do not want to infringe on Larry's
trademark) is. It is not worth the effort and in fact your work supports
using that proprietary tool. I suggest to completely remove the project.
-- 
Pavel Janík

In protocol design, perfection has been reached not when there is nothing
left to add, but when there is nothing left to take away.
                  -- RFC1925: The Twelve Networking Truths

Re: BitBucket: GPL-ed KitBeeper clone

[Christoph Hellwig]

On Sat, Mar 01, 2003 at 07:05:35PM +0100, Pavel Janík wrote:
> I think that it is waste of your valuable time to create clones of
> proprietary software like KitBeeper (I do not want to infringe on Larry's
> trademark) is. It is not worth the effort and in fact your work supports
> using that proprietary tool. I suggest to completely remove the project.

I totally agree.  We should stop developing Linux now and remove all source
code from kernel.org because it's reimplementation and further development
of the APIs of the propritary "UNIX" operating system is just a waste of
time.

Re: BitBucket: GPL-ed KitBeeper clone

[Paul Fulghum]

On Sat, 2003-03-01 at 12:05, Pavel Janík wrote:
> ...software like KitBeeper (I do not want to
> infringe on Larry's trademark)...

That's certainly less rude than ButtCreeper :-)
(Sorry, I'll shut the Hell up now)

-- 
Paul Fulghum paulkf@microgate.com
Microgate Corporation http://www.microgate.com

Re: BitBucket: GPL-ed KitBeeper clone

[Pavel Janík]

   From: Christoph Hellwig <hch@infradead.org>
   Date: Sat, 1 Mar 2003 18:39:29 +0000

   > I totally agree.  We should stop developing Linux now and remove all
   > source code from kernel.org because it's reimplementation and further
   > development of the APIs of the propritary "UNIX" operating system is
   > just a waste of time.

You misunderstood my reply. We do have many source control management
software around. Instead of developing something to be able to work with
proprietary systems, we should concentrate on adding missing pieces to
existing software and trying to convince people to not use proprietary
systems because of their freedom. E.g. Linus and other people exercising
"free" KitBeeper license now can not develop SCM software even if they want
to. I think this is really bad for their freedom.

And what will be the next thing?
-- 
Pavel Janík

I wouldn't like to have something like fetchmail for the kernel
configuration.
                  -- Martin Dalecki in LKML about CML2

Re: BitBucket: GPL-ed KitBeeper clone

[Mike Galbraith]

At 02:58 PM 3/1/2003 -0600, Paul Fulghum wrote:
>On Sat, 2003-03-01 at 12:05, Pavel Janík wrote:
> > ...software like KitBeeper (I do not want to
> > infringe on Larry's trademark)...
>
>That's certainly less rude than ButtCreeper :-)
>(Sorry, I'll shut the Hell up now)

Hey, that was pretty good.  Maybe a bit of humor will help keep folks from 
getting excited (again) and ranting all over my mailbox (again and again...)

<peek>  darn ;-)

         -Mike

Re: BitBucket: GPL-ed BitKeeper clone

[Ben Collins]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

On Wed, Feb 26, 2003 at 09:02:12PM +0100, Pavel Machek wrote:
> Hi!
> 
> I've created little project for read-only (for now ;-) bitkeeper
> clone. It is available at www.sf.net/projects/bitbucket (no tar balls,
> just get it fresh from CVS).

In case it may be of some help, here's a script that is the result of my
own reverse engineering of the bitkeeper SCCS files. It can output a
diff, almost exactly the same as BitKeeper's gnupatch output from a
BitKeeper repo.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

[-- Attachment #2: bitsubversion.pl --]
[-- Type: text/plain, Size: 10089 bytes --]

#!/usr/bin/perl -w

#
# Licensed under the GNU General Public License v2
#
# Copyright (C) 2002 Ben Collins <bcollins@debian.org>
#

#
# This script will take one arg, that of a BitKeeper ChangeSet ID. It will
# then extract information from the current directory (expected to be a
# BitKeeper repository) to export a GNU Patch style output of the
# ChangeSet. It tries to be as close as possible to the gnupatch output
# from BitKeeper itself.
#
# This program requires the GNU CSSC suite to operate on the files. It
# also requires a patch to that suite so that it interoperates better with
# a BitSCCS style repository.
#
# You can get a list of ChangeSet ID's with this command:
#
# sccs prs -e -d:I: ChangeSet | less
#

use File::Basename;
use strict;

# Forward declerations
sub print_comment($;$;$;$);
sub get_prev_rev($;$);
sub resolve_sccs_loc($;$;$);

if (@ARGV != 1) {
	print STDERR "Usage: bitsubversion <sid>\n";
	exit 1;
}

if (not -f "SCCS/s.ChangeSet") {
        print STDERR "Must be in a BitKeeper repo for this script to work\n";
        exit 1;
}

my $rev = shift @ARGV;
my $prevrev = get_prev_rev("ChangeSet", $rev);

# Get the comments for this rev
open (COMMENTS, "sccs prs -r$rev '-d:D:\\n:P:\\n:C:' ChangeSet |") or die "opening sccs prs";
my $comments = "";
my $revdate = <COMMENTS>;
my $revperp = <COMMENTS>;
chomp $revdate;
chomp $revperp;
while (<COMMENTS>) {
	last if m/^C: $/;
	$comments = $comments . "# $_";
}
close COMMENTS;

my @changes = ();
my $revuser = "";

open (PROJ, "sccs get -p BitKeeper/etc/config |") or die "opening BitKeeper/etc/config";
my $desc = "";
while (<PROJ>) { $desc = $1 if m/^description: (.*)/; }
close PROJ;

print "# This is a BitSubversion generated patch for the following project:\n";
print "# Project Name: $desc\n";
print "# This patch format is intended for GNU patch command version 2.5 or higher.\n";
print "# This patch includes the following deltas:\n";

print_comment("ChangeSet", $prevrev, $rev, "ChangeSet");

open(CSETDIFF, "sccs sccsdiff -u -r$prevrev -r$rev ChangeSet |") or die "opening sccs sccsdiff";
while (<CSETDIFF>) {
	chomp;
	next if not m/^\+.*\|.*/;

	my ($origcset, $csetkey) = split / /;
	my $new = {};

	# user@host|path/in/repo|YYYYMMDDHHMMSS|key
	my ($userhost, $file, $date, $key) = split /\|/, $csetkey;

	# user@host|path/in/repo|YYYYMMDDHHMMSS|key|crc?
	my ($prevuserhost, $origfile, $junk2, $origkey, $crc) = split /\|/, $origcset;

	$revuser = $userhost if $revuser eq "";

	$new->{'file'} = $file;
	$new->{'origfile'} = $origfile;
	$new->{'origkey'} = $origkey;
	$new->{'crc'} = $crc;

	# Resolve the location of the file
	$new->{'sccsfile'} =
		resolve_sccs_loc($new->{'file'}, $new->{'origkey'}, $new->{'crc'});

	my ($usr1) = split /\@/, $userhost;
	my ($usr2) = split /\@/, $prevuserhost;

	# Get the current and previous SID
	open(PRS, "sccs prs '-dCSET: :I:\\n:P:\\n:C:' -e $new->{'sccsfile'} |") or
		die "opening sccs prs";
	$new->{'sid'} = "";
	$new->{'parentfile'} = "(none)";
	while (<PRS>) {
		if (m/^P: (.*)$/) {
			if ($new->{'sid'} ne "" and $new->{'parentfile'} eq "") {
				$new->{'parentfile'} = $1;
			} elsif ($new->{'parentfile'} eq "(none)") {
				$new->{'parentfile'} = "";
			}
		}

		next if not m/^CSET: (.*)$/;
		my $sid = $1;

		my $perp = <PRS>;
		chomp $perp;

		if ($new->{'sccsfile'} =~ m/^BitKeeper\/deleted\/\.del-/) {
			$new->{'parentfile'} = <PRS>;
			chomp $new->{'parentfile'};
			$new->{'parentfile'} = s/^Deleted: //;
		}

		my $thiskey = "";
		while (<PRS>) {
			if (m/^K: (.*)$/) {
				$thiskey = $1;
				last;
			}
		}

		# This can be tricky folks. Even though we have a key, it
		# is not unique. There's two other parts of the ChangeSet
		# that BK uses as the complete key.
		#
		# One of the other parts is the date, given in
		# YYYYMMDDHHMMSS. However it's totally useless it seems. I
		# tried comparing it, and sometimes the date of the delta
		# is a few seconds off from this date. I could do an
		# approximation, but I'm too lazy. Also, CSSC is not very
		# good at using this date to limit prs output.
		#
		# The second part of the key is the user (perp, or :P:
		# under SCCS). This gives us a good chance at hitting the
		# right delta.
		next if $thiskey ne $key or
			($perp ne $revperp and $perp ne $usr1 and $perp ne $usr2);

		$new->{'sid'} = $sid;
	}
	close PRS;

	$new->{'parentfile'} = $new->{'file'} if $new->{'parentfile'} eq "" or
		$new->{'parentfile'} eq "(none)";

	$new->{'prevsid'} = get_prev_rev($new->{'sccsfile'}, $new->{'sid'});

	print_comment($new->{'file'}, $new->{'prevsid'}, $new->{'sid'}, $new->{'parentfile'});

	unshift @changes, $new;
}

close CSETDIFF;

print "#\n";
print "# The following is the ChangeSet Log\n";
print "# --------------------------------------------\n";
print "# $revdate\t$revuser\t$rev\n";
print $comments;
print "# --------------------------------------------\n";
print "#\n";

open(DATE, "date '+%a %b %e %T %G' |") or die "opening data";
my $diffdate = <DATE>;
chomp $diffdate;
close DATE;

foreach my $entry (@changes) {
	my $sid = $entry->{'sid'};
	my $prevsid = $entry->{'prevsid'};
	my $sccsfile = $entry->{'sccsfile'};
	my $diffpath;
	my $moving = 0;

	die "$entry->{'file'} has illegal empty sid/prevsid" if $sid eq "" or $prevsid eq "";

	if ($entry->{'file'} =~ m/^BitKeeper\/deleted\/\.del-/) {
		# SCCS will handle this by saying the revs are alike
		# (which they are), so we use our hacked sccsdiff and pass
		# 1 as the second sid.
		$sid = "1";
		$diffpath = $entry->{'parentfile'};
	} elsif ($entry->{'parentfile'} ne $entry->{'file'}) {
		$moving = 1;
	} else {
		$diffpath = $entry->{'file'};
	}

	while (1) {
		my ($mysid, $myprevsid);

		if ($moving) {
			if ($moving == 1) {
				# Delete first
				$diffpath = $entry->{'file'};
				$mysid = 1;
				$myprevsid = $prevsid;
				# Print an informative header
				print "ByteSubvert: move\n";
				print "FromFile: $entry->{'file'}\n";
				print "ToFile: $entry->{'parentfile'}\n";
				$moving = 2;
			} else {
				# Now create the new file
				$diffpath = $entry->{'parentfile'};
				$mysid = $sid;
				$myprevsid = 1;
				$moving = 0;
			}
		} else {
			$mysid = $sid;
			$myprevsid = $prevsid;
		}

		open(DIFF, "sccs sccsdiff -u -r$myprevsid -r$mysid $sccsfile |")
			or die "opening sccs sccsdiff";

		while (<DIFF>) {
			if (m/^$sccsfile/) {
				print "diff -Nru a/$diffpath b/$diffpath\n";
				next;
			}
			if (m/^--- \/tmp/) {
				# For new files, we hack the date so that patch
				# treats it correctly. Without this, patch would
				# allow this "new" diff to be applied onto an
				# existing file. This way, patch knows that it is
				# dealing with a new file, and errors if the file
				# exists.
				if ($myprevsid eq "1") {
					print "--- /dev/null\tWed Dec 31 16:00:00 1969\n";
				} else {
					print "--- a/$diffpath\t$diffdate\n";
				}
				next;
			} elsif (m/^\+\+\+ \/tmp/) {
				# For deleted files, we do the same thing, but on
				# the "removed" side.
				if ($mysid eq "1") {
					print "+++ /dev/null\tWed Dec 31 16:00:00 1969\n";
				} else {
					print "+++ b/$diffpath\t$diffdate\n";
				}
				next;
			}
			print $_;
		}

		last if not $moving;
	}
	close (DIFF);
}

sub get_prev_rev($;$) {
	my $file = shift;
	my $sid = shift;
	my $prevsid;

	open(PRS, "sccs prs -r$sid -d:DP: $file |") or die "opening sccs prs";
	my $dp = <PRS>;
	chomp $dp;
	close PRS;

	open(PRS, "sccs prs -e -d:I:::DS: $file |") or die "opening sccs prs";
	while (<PRS>) {
		chomp;
		my ($thissid, $ds) = split /:/;
		if ($ds eq $dp) {
			$prevsid = $thissid;
			last;
		}
	}
	close PRS;

	die "could not find prevrev for $file" if not defined($prevsid);

	return $prevsid;
}

sub resolve_sccs_loc($;$;$) {
	my $curpath = shift;
	my $origkey = shift;
	my $crc = shift;
	my ($file, $dir, $sccsfile);

	# The BitKeeper/etc/SCCS/x.id_cache file seems to contain history
	# of how files move around the repo, and possibly eventually
	# become deleted and end up in BitKeeper/deleted/.
	#
	# We'll abuse that file directly to find an arbitrary file at any
	# point during the repo's history. Remember boys and girls, a file
	# can move more than once. We use the initial file key and crc
	# (found from the file entries pertaining to the ChangeSet) to
	# make sure we match things up properly.

	open(ID, "< BitKeeper/etc/SCCS/x.id_cache") or die "opening id_cache";
	while (<ID>) {
		chomp;

		next if not m/\|/;

		my ($tmp, $newloc) = split / /;

		# user@host|path/to/file|YYYYMMDDHHMMSS|key|crc?
		my ($junk1, $prevpath, $junk2, $thiskey, $thiscrc) =
			split /\|/, $tmp;

		next if $origkey ne $thiskey or $curpath ne $prevpath or $crc ne $thiscrc;

		$curpath = $newloc;
	}
	close ID;

	($file,$dir) = fileparse($curpath);
	$dir = "" if $dir eq "./";

	$sccsfile = "${dir}SCCS/s.$file";

	die "could not locate SCCS file for $curpath (via $sccsfile)" if not -f $sccsfile;

	return $sccsfile;
}

sub print_comment($;$;$;$) {
	my $file = shift;
	my $prevrev = shift;
	my $rev = shift;
	my $origfile = shift;
	my ($pathstr1, $pathstr2, $prevrevstr, $revstr);

	my $len1 = 26;	# Padding before first path
	my $len2 = 7;	# Padding between prevrev and "->"
	my $len3 = 8;	# Padding after second rev and following str

	if ($prevrev eq "1" or $prevrev eq "1.0") {		# New
		$pathstr1 = ' 'x($len1-length("(new)")) . "(new)";
		$pathstr2 = $file;
		$prevrevstr = ' 'x$len2;
		$revstr = $rev . ' 'x($len3-length($rev));
	} elsif ($file =~ m/^BitKeeper\/deleted\/\.del-/) {	# Deleted
		$pathstr1 = ' 'x($len1-length($origfile)) . $origfile;
		$pathstr2 = "(deleted)";
		$prevrevstr = $prevrev . ' 'x($len2-length($prevrev));
		$revstr = ' 'x$len3;
	} elsif ($file ne $origfile) {				# Moved
		$pathstr1 = ' 'x($len1-length($origfile)) . $origfile;
		$pathstr2 = "$file (moved)";
		$prevrevstr = $prevrev . ' 'x($len2-length($prevrev));
		$revstr = $rev . ' 'x($len3-length($rev));
	} else {						# Changed
		$pathstr1 = ' 'x($len1-length($file)) . $file;
		$pathstr2 = "";
		$prevrevstr = $prevrev . ' 'x($len2-length($prevrev));
		$revstr = $rev;
	}

	print "# $pathstr1\t$prevrevstr -> $revstr$pathstr2\n";
}

Re: BitBucket: GPL-ed BitKeeper clone

[Ben Collins]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

On Sun, Mar 02, 2003 at 12:04:20AM -0500, Ben Collins wrote:
> On Wed, Feb 26, 2003 at 09:02:12PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > I've created little project for read-only (for now ;-) bitkeeper
> > clone. It is available at www.sf.net/projects/bitbucket (no tar balls,
> > just get it fresh from CVS).
> 
> In case it may be of some help, here's a script that is the result of my
> own reverse engineering of the bitkeeper SCCS files. It can output a
> diff, almost exactly the same as BitKeeper's gnupatch output from a
> BitKeeper repo.


Might aswell supply my hacked sccsdiff script aswell.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

[-- Attachment #2: sccsdiff --]
[-- Type: text/plain, Size: 4873 bytes --]

#! /bin/sh

# This file is part of CSSC.
# # Generated automatically from sccsdiff.sh.in by configure.

# Usage:
# sccsdiff [-p] -rsid -rsid [diff-options] s.filename
#

# $Id: sccsdiff.sh.in,v 1.9 2001/11/25 16:01:38 james_youngman Exp $
# LOG   $Log: sccsdiff.sh.in,v $
# LOG   Revision 1.9  2001/11/25 16:01:38  james_youngman
# LOG   Corrected a syntax error.
# LOG
# LOG   Revision 1.8  2001/11/25 14:27:54  james_youngman
# LOG   fixed Debian  Bug#120080: sccs sccsdiff doesn't work (sccsdiff assumes /usr/sccs symlink exists)
# LOG
# LOG   Revision 1.7  1998/03/10 00:22:00  james
# LOG   Support for filenames containing spaces.
# LOG
# LOG   Revision 1.6  1998/03/09 23:25:00  james
# LOG   Bug report from Richard Polton: IRIX's pr(1) requires a space between
# LOG   the "-h" and its argument.
# LOG
# LOG   Revision 1.5  1998/02/09 21:00:19  james
# LOG   Patch from Maurice O'Donnell <mod@tfn.com>: pass "-e" to sed before
# LOG   the sed commands.
# LOG
# LOG   Revision 1.4  1998/01/24 14:15:13  james
# LOG   SCCS compatibility fix -- When "get" fails, exit with value 1, not 2.
# LOG
# LOG   Revision 1.3  1997/12/19 20:40:35  james
# LOG   Modified version of sccsdiff arrived from Richard Polton; took the
# LOG   ideas onboard for a rewrite of sccsdiff.
# LOG
# LOG   Revision 1.2  1997/05/04 14:52:02  james
# LOG   Have to enclose the version string in single rather than double
# LOG   quotes, to protect the dollar signs from shell expansion.
# LOG
# LOG   Revision 1.1  1997/05/04 14:49:22  james
# LOG   Initial revision

# Values substituted by configure:-
pr=/usr/bin/pr			   # The location of the   pr(1) command:
diff=/usr/bin/diff # The location of the diff(1) command:

# Find the "get" command.  The last value tested is "get", and 
# that's what we use if we can't find get in any other location.
if test x$get = x
then
    # The CSSC Makefile performs a sed substitution on the next line.
    for get in "/usr/local/libexec/cssc/get" /usr/sccs/get get
    do
	if [ -x "$get" ]
	then
	    break
	fi
    done
fi

version='$Revision: 1.9 $ $State: Exp $'
usage() {
cat <<EOF
$0 [-p] -rsid -rsid [diff-options] s.filename [s.secondfile...]
EOF
}

use_pr=false
first_sid=
second_sid=
diff_options=
sccs_files=

while test $# -gt 0
do
	case $1 in 
	    --help)
		usage
		exit 0
		;;
	    --version)
		echo "$version"
		exit 0
		;;
	    -p) use_pr=true 
		shift
		;;
	    -r*)      
		if test x$first_sid = x
		then
		    first_sid=$1
		else
		    if test x$second_sid = x
		    then
			second_sid=$1
		    else
			exec >&2
			usage
			echo "Too many -r options."
			exit 1
		    fi
		fi
		shift
		;;
	    -*)
		diff_options="${diff_options} $1"
		shift
		;;
	    *)  
		# That is an SCCS file, leave it and everything 
		# following it in $*.
		break
		;;
	esac
done

# Show what we got...
## echo "use_pr=" $use_pr
## echo "first SID=" $first_sid
## echo "second SID=" $second_sid
## echo "diff options=" $diff_options
## echo "SCCS files=" $*
## echo \$\# = $#

if test x$second_sid = x
then
    exec >&2
    echo Two SIDs must be specified with the -r option.
    usage
    exit 1
fi


# Remove the leading "-r" from $first_sid and $second_sid
# so that we can echo the correct string as the header line
# introducing the diff.
first_sid=`echo   $first_sid | sed -e 's/^-r//' `
second_sid=`echo $second_sid | sed -e 's/^-r//' `

getprefix=/tmp/get.$$.
g1="${getprefix}${first_sid}"
g2="${getprefix}${second_sid}"
dfile=${getprefix}d${first_sid}${second_sid}

while test $# -gt 0
do
    rm -f "$g1" "$g2" "$dfile"
    sccsfile="$1"
    shift 

    header="$sccsfile: $first_sid vs. $second_sid"

    if test $first_sid = 1 -o $first_sid = 1.0; then
	touch "${g1}"
    else
	${get:-get} -r$first_sid -s -k "-G${g1}" "${sccsfile}" || {
	    exec >&2
	    echo "Failed to get version $first_sid from $sccsfile"
	    exit 1
	}
    fi
    if test $second_sid = 1 -o $second_sid = 1.0; then
	touch "${g2}"
    else
	${get:-get} -r$second_sid -s -k "-G${g2}" "${sccsfile}" || {
	    rm -f "$g1"
	    exec >&2
	    echo "Failed to get version $second_sid from $sccsfile"
	    exit 1
        }
    fi

    # in case noclobber is set...
    rm -f "$dfile"

    # Ignore return value of diff since it just tells us
    # if the two files are different.
    "$diff" $diff_options "$g1" "$g2" > "$dfile"
    if test -f "$dfile" 
    then				  # Output file exists.
        if test -s "$dfile" 
        then				  # Output file is not empty.
	    if $use_pr
	    then
		$pr -h "$header"        < $dfile  
	    else
		echo $header
		cat "$dfile"
	    fi
        else				  # Output file is empty.
	    echo No differences.
	fi
    else				  # No output file at all!
        echo "$diff produced no output file." >&2
        exit 2
    fi
done					  # Loop over all named SCCS files.
rm -f "$g1" "$g2" "$dfile"
exit 0

# Local Variables:
# Mode: shell
# End:

Re: BitBucket: GPL-ed KitBeeper clone

[Christoph Hellwig]

On Sat, Mar 01, 2003 at 11:43:23PM +0100, Pavel Janík wrote:
> You misunderstood my reply. We do have many source control management
> software around. Instead of developing something to be able to work with
> proprietary systems, we should concentrate on adding missing pieces to
> existing software

Well, that's the same argument as we don't need UNIX we have DOS.

But anyway, don't you think Pavel is free to develop whatever free software
he likes to develop instead of following you political agenda?

Re: BitBucket: GPL-ed KitBeeper clone

[John Bradford]

> But anyway, don't you think Pavel is free to develop whatever free
> software he likes to develop instead of following you political
> agenda?

What is the goal of the BitBucket project, though?

To develop a version control system, or to annoy Larry?

I haven't seen a single post to the list saying, "If we were designing
a version control system dedicated to the Linux kernel, what would you
like to see in it?".  Before I started work on my bug database, I
spent a week or so discussing it on the list with people.

Why doesn't somebody start working on a dedicated kernel version
control system?

John.

Re: BitBucket: GPL-ed KitBeeper clone

[Christoph Hellwig]

On Sun, Mar 02, 2003 at 09:30:00AM +0000, John Bradford wrote:
> > But anyway, don't you think Pavel is free to develop whatever free
> > software he likes to develop instead of following you political
> > agenda?
> 
> What is the goal of the BitBucket project, though?
> 
> To develop a version control system, or to annoy Larry?

Given the annoucement probably access the kernel BK tree in real time.

> Why doesn't somebody start working on a dedicated kernel version
> control system?

It's called BitKeeper :)

Re: BitBucket: GPL-ed KitBeeper clone

[Pavel Janík]

   From: Christoph Hellwig <hch@infradead.org>
   Date: Sun, 2 Mar 2003 09:11:30 +0000

   > But anyway, don't you think Pavel is free to develop whatever free software
   > he likes to develop instead of following you political agenda?

Of course he is - it is one of his freedom. I only wanted to show him that
there are (IMO) better ways to spend his time. And it is no about
politics...
-- 
Pavel Janík

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

                  -- Rik van Riel in linux-kernel

Re: BitBucket: GPL-ed BitKeeper clone

[Pavel Machek]

> BitKeeper is a trademark, please don't use the BitKeeper name when
> describing BitBucket.  Thanks.

Sorry, I should have been more carefull about wording. Sourceforge
page states that 

Goal of this project is to create version managment system compatible
with BitKeeper.

I hope that's okay with you.
								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: BitBucket: GPL-ed BitKeeper clone

[Pavel Machek]

Hi!

> > > I've created little project for read-only (for now ;-) bitkeeper
> > > clone. It is available at www.sf.net/projects/bitbucket (no tar balls,
> > > just get it fresh from CVS).
> > 
> > In case it may be of some help, here's a script that is the result of my
> > own reverse engineering of the bitkeeper SCCS files. It can output a
> > diff, almost exactly the same as BitKeeper's gnupatch output from a
> > BitKeeper repo.
> 
> Might aswell supply my hacked sccsdiff script aswell.

There's a problem with this: it changes CSSC, and its GNU (read: needs
copyright assignment to apply changes). I can't really push your
changes to CSSC :-(. [What I can do is add .diff file into
bitbucket...]
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: BitBucket: GPL-ed KitBeeper clone

[Pavel Machek]

Hi!

>    > I've created little project for read-only (for now ;-) kitbeeper
>    > clone. It is available at www.sf.net/projects/bitbucket (no tar balls,
>    > just get it fresh from CVS).
> 
> I think that it is waste of your valuable time to create clones of
> proprietary software like KitBeeper (I do not want to infringe on Larry's
> trademark) is. It is not worth the effort and in fact your work supports
> using that proprietary tool. I suggest to completely remove the
> project.

Actually bk's on-disk format is quite reasonable, and there's a *lot*
of example data in that format, so it might be easier to develop
free version control system this way.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: BitBucket: GPL-ed BitKeeper clone

[Ben Collins]

On Mon, Mar 03, 2003 at 12:53:18AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > I've created little project for read-only (for now ;-) bitkeeper
> > > > clone. It is available at www.sf.net/projects/bitbucket (no tar balls,
> > > > just get it fresh from CVS).
> > > 
> > > In case it may be of some help, here's a script that is the result of my
> > > own reverse engineering of the bitkeeper SCCS files. It can output a
> > > diff, almost exactly the same as BitKeeper's gnupatch output from a
> > > BitKeeper repo.
> > 
> > Might aswell supply my hacked sccsdiff script aswell.
> 
> There's a problem with this: it changes CSSC, and its GNU (read: needs
> copyright assignment to apply changes). I can't really push your
> changes to CSSC :-(. [What I can do is add .diff file into
> bitbucket...]

I'm putting my changes to CSSC into the public domain. The FSF can do
whatever it wants.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/

Re: BitBucket: GPL-ed KitBeeper clone

[Helge Hafting]

Pavel Janík wrote:
 >  E.g. Linus and other people exercising
> "free" KitBeeper license now can not develop SCM software even if they want
> to. I think this is really bad for their freedom.

I wouldn't worry.  Linus can develop any SCM software he want to, he 
merely have to drop bitkeeper first if he do.  There is no freedom 
problem here.  His current use of bitkeeper simply means he isn't
into developing scm systems right now.  Which probably is
a good thing.

Helge Hafting

Re: BitBucket: GPL-ed KitBeeper clone

[Bernd Eckenfels]

In article <3E630CD9.9010906@aitel.hist.no> you wrote:
> I wouldn't worry.  Linus can develop any SCM software he want to

Linus is not the only kernel hacker, and there are quite a few who work on
SCMs.

Gruss
Bernd
-- 
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/

Re: BitBucket: GPL-ed KitBeeper clone

[Pavel Machek]

Hi!

> > But anyway, don't you think Pavel is free to develop whatever free
> > software he likes to develop instead of following you political
> > agenda?
> 
> What is the goal of the BitBucket project, though?
> 
> To develop a version control system, or to annoy Larry?

To be able to access kernel version history without touching
bk. Annoying Larry is just a side effect, altrough I agree selection
of project name was "interesting" ;-).

> I haven't seen a single post to the list saying, "If we were designing
> a version control system dedicated to the Linux kernel, what would you
> like to see in it?".  Before I started work on my bug database, I
> spent a week or so discussing it on the list with people.

Apparently Linus, DaveM and Larry did just this, 2 years ago and
offline. bk is result of that discussion.

> Why doesn't somebody start working on a dedicated kernel version
> control system?

That's way harder than accessing kernel version history. I do not have
time for *that*. 
								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: BitBucket: GPL-ed KitBeeper clone

[John Bradford]

> > I haven't seen a single post to the list saying, "If we were designing
> > a version control system dedicated to the Linux kernel, what would you
> > like to see in it?".  Before I started work on my bug database, I
> > spent a week or so discussing it on the list with people.
> 
> Larry spent a lot of time talking to people directly about such things.

I meant in relation to Bit Bucket.

If the need for Bit Keeper to make a profit for Bit Mover excludes
Linux developers from using it, the most logical thing to do in my
opinion is to start from scratch and write a version control system
dedicated to furthering Linux kernel development.

Compatibility with Bit Keeper should not be a goal of that project.

John.

Re: BitBucket: GPL-ed KitBeeper clone

[Alan Cox]

On Sun, 2003-03-02 at 09:30, John Bradford wrote:
> I haven't seen a single post to the list saying, "If we were designing
> a version control system dedicated to the Linux kernel, what would you
> like to see in it?".  Before I started work on my bug database, I
> spent a week or so discussing it on the list with people.

Larry spent a lot of time talking to people directly about such things.

Re: BitBucket: GPL-ed KitBeeper clone

[Richard B. Johnson]

On Mon, 3 Mar 2003, John Bradford wrote:

> > > I haven't seen a single post to the list saying, "If we were designing
> > > a version control system dedicated to the Linux kernel, what would you
> > > like to see in it?".  Before I started work on my bug database, I
> > > spent a week or so discussing it on the list with people.
> > 
> > Larry spent a lot of time talking to people directly about such things.
> 
> I meant in relation to Bit Bucket.
> 
> If the need for Bit Keeper to make a profit for Bit Mover excludes
> Linux developers from using it, the most logical thing to do in my
> opinion is to start from scratch and write a version control system
> dedicated to furthering Linux kernel development.
> 
> Compatibility with Bit Keeper should not be a goal of that project.
                                ^^^^^^^^^^^^^^^^^^^^
> 
> John.

Hmmm. Compatibility with existing things is always one of the
considerations of any new product (or project). If compatibility
can be achieved without a significant trade-off in performance,
then it should become one of the goals.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: BitBucket: GPL-ed KitBeeper clone

[Charles Cazabon]

John Bradford <john@grabjohn.com> wrote:
> > 
> > Larry spent a lot of time talking to people directly about such things.
> 
> I meant in relation to Bit Bucket.
> 
> If the need for Bit Keeper to make a profit for Bit Mover excludes
> Linux developers from using it, the most logical thing to do in my
> opinion is to start from scratch and write a version control system
> dedicated to furthering Linux kernel development.
> 
> Compatibility with Bit Keeper should not be a goal of that project.

Larry did a pretty good job of determining what the software needed to do to
be useful for the linux-kernel project.  Any possible replacement that doesn't
do at least what bitkeeper does is likely dead before it starts.

(nevermind that no replacement is necessary, due to Larry's gratis provision
of the tool to kernel developers...)

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <linux@discworld.dyndns.org>
GPL'ed software available at:     http://www.qcc.ca/~charlesc/software/
-----------------------------------------------------------------------

Re: BitBucket: GPL-ed KitBeeper clone

[John Bradford]

> > > > I haven't seen a single post to the list saying, "If we were designing
> > > > a version control system dedicated to the Linux kernel, what would you
> > > > like to see in it?".  Before I started work on my bug database, I
> > > > spent a week or so discussing it on the list with people.
> > > 
> > > Larry spent a lot of time talking to people directly about such things.
> > 
> > I meant in relation to Bit Bucket.
> > 
> > If the need for Bit Keeper to make a profit for Bit Mover excludes
> > Linux developers from using it, the most logical thing to do in my
> > opinion is to start from scratch and write a version control system
> > dedicated to furthering Linux kernel development.
> > 
> > Compatibility with Bit Keeper should not be a goal of that project.
>                                 ^^^^^^^^^^^^^^^^^^^^
> Hmmm. Compatibility with existing things is always one of the
> considerations of any new product (or project).

I did consider it, I just don't think it's a good idea.

> If compatibility can be achieved without a significant trade-off in
> performance, then it should become one of the goals.

Agreed, but in a project to develop the best possible version control
system for the Linux kernel [1], I don't see how compatibility with
any other version control system is of any interest at all.

It's only if you want to use several version control systems in
parallel that it might be an issue, but if a single, free, version
control system is in use, I don't see why that would be necessary.

Getting the data out of Bit Keeper and in to a different version
control system is a one-time job, and as far as I am aware there is
no difficulty getting data out of a Bit Keeper repository, (using Bit
Keeper itself), in a suitable format.

[1] As distinct from projects to develop the best possible version
control system in general or to develop a GPLed project to complete
with Bit Keeper.

John.

Re: BitBucket: GPL-ed KitBeeper clone

[David Lang]

the big reason for haveing it be compatable with existing systems is so
that if people move to it and decide they don't like it they can move away
from it again.

you may like to think that your program is so good that people will never
want to move away, but if it isn't an option then people will be very slow
to adopt it as the risk to their source history just went up a few
notches.

David Lang


 On Mon, 3 Mar 2003, John Bradford wrote:

> Date: Mon, 3 Mar 2003 15:08:15 +0000 (GMT)
> From: John Bradford <john@grabjohn.com>
> To: root@chaos.analogic.com
> Cc: alan@lxorguk.ukuu.org.uk, hch@infradead.org, pavel@janik.cz, pavel@ucw.cz,
>      linux-kernel@vger.kernel.org
> Subject: Re: BitBucket: GPL-ed KitBeeper clone
>
> > > > > I haven't seen a single post to the list saying, "If we were designing
> > > > > a version control system dedicated to the Linux kernel, what would you
> > > > > like to see in it?".  Before I started work on my bug database, I
> > > > > spent a week or so discussing it on the list with people.
> > > >
> > > > Larry spent a lot of time talking to people directly about such things.
> > >
> > > I meant in relation to Bit Bucket.
> > >
> > > If the need for Bit Keeper to make a profit for Bit Mover excludes
> > > Linux developers from using it, the most logical thing to do in my
> > > opinion is to start from scratch and write a version control system
> > > dedicated to furthering Linux kernel development.
> > >
> > > Compatibility with Bit Keeper should not be a goal of that project.
> >                                 ^^^^^^^^^^^^^^^^^^^^
> > Hmmm. Compatibility with existing things is always one of the
> > considerations of any new product (or project).
>
> I did consider it, I just don't think it's a good idea.
>
> > If compatibility can be achieved without a significant trade-off in
> > performance, then it should become one of the goals.
>
> Agreed, but in a project to develop the best possible version control
> system for the Linux kernel [1], I don't see how compatibility with
> any other version control system is of any interest at all.
>
> It's only if you want to use several version control systems in
> parallel that it might be an issue, but if a single, free, version
> control system is in use, I don't see why that would be necessary.
>
> Getting the data out of Bit Keeper and in to a different version
> control system is a one-time job, and as far as I am aware there is
> no difficulty getting data out of a Bit Keeper repository, (using Bit
> Keeper itself), in a suitable format.
>
> [1] As distinct from projects to develop the best possible version
> control system in general or to develop a GPLed project to complete
> with Bit Keeper.
>
> John.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: BitBucket: GPL-ed KitBeeper clone

[Pavel Machek]

Hi!

> It's only if you want to use several version control systems in
> parallel that it might be an issue, but if a single, free, version
> control system is in use, I don't see why that would be necessary.

But you *will* be using bitkeeper along with something else, because
linus is not going to switch unless that something else is well
tested, creating chicken-egg problem.

-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: BitBucket: GPL-ed KitBeeper clone

[John Bradford]

> > It's only if you want to use several version control systems in
> > parallel that it might be an issue, but if a single, free, version
> > control system is in use, I don't see why that would be necessary.
> 
> But you *will* be using bitkeeper along with something else, because
> linus is not going to switch unless that something else is well
> tested, creating chicken-egg problem.

Well, you could try convincing Alan to use it for the -ac trees, or
the 2.2 kernel to get it tested with a real dataset.

John.