* RFC - tarball/patch server in BitKeeper
@ 2003-12-14 17:21 Larry McVoy
2003-12-14 23:05 ` Keith Owens
` (4 more replies)
0 siblings, 5 replies; 35+ messages in thread
From: Larry McVoy @ 2003-12-14 17:21 UTC (permalink / raw)
To: linux-kernel; +Cc: bitkeeper-users
Merry Christmas.
I've prototyped an extension to BitKeeper that provides tarballs
and patches. The idea is to make it possible for all trees hosted by
bkbits.net provide access to the data with a free client (included below
in prototype form).
The system is simplistic, it just provides a way to get the most recent
sources as a tarball and then any later updates as a patch. There is
no provision for generating diffs, editing files, merging, etc. All of
that is something that you can write, if you want, using standard tools
(think hard linked trees).
Before rolling this out, I want to know if this is going to (finally)
put to rest any complaints about BK not being open source, available on
all platforms, etc. You need to understand that this is all you get,
we're not going to extend this so you can do anything but track the most
recent sources accurately. No diffs. No getting anything but the most
recent version. No revision history.
If you want anything other than the most recent version your choices
are to use BitKeeper itself or, if you want the main branches of the
Linux kernel, the BK2CVS exports. This is not a gateway product, it
is a way for developers to track the latest and greatest with a free
(source based) client. It is not a way to convert BK repos to $SCM.
If the overwhelming response is positive then I'll add this to the
bkbits.net server and perhaps eventually to the BK product itself.
--lm
Example of it being used on the mysql BK repo (note that server/port is
hardwired, it is a prototype after all)
$ rm -rf tmp
$ tarball
OK-tarball coming, 10535416 bytes to transfer...
OK-tarball transferred, enjoy!
$ ls -F tmp
BUILD/ cmd-line-utils/ libmysqld/ pstack/
BitKeeper/ config.guess* ltconfig* regex/
Build-tools/ config.sub* ltmain.sh scripts/
Docs/ configure.in man/ sql/
INSTALL-WIN-SOURCE dbug/ merge/ sql-bench/
Makefile.am depcomp* missing* sql-common/
NEW-RPMS/ extra/ mkinstalldirs* strings/
README heap/ myisam/ support-files/
SSL/ include/ myisammrg/ tests/
VC++Files/ innobase/ mysql-test/ tools/
acconfig.h install-sh* mysys/ vio/
acinclude.m4 isam/ mytest-old.c zlib/
bdb/ libmysql/ netware/
client/ libmysql_r/ os2/
$ update
INFO-generating patch, please wait...
OK-patch coming, 6053 bytes...
patching file mysql-test/r/query_cache.result
patching file mysql-test/r/sp-error.result
patching file mysql-test/r/sp.result
patching file mysql-test/r/variables.result
patching file mysql-test/t/sp-error.test
patching file mysql-test/t/sp.test
patching file sql/handler.cc
patching file sql/handler.h
patching file sql/item_subselect.cc
patching file sql/lex.h
patching file sql/slave.cc
patching file sql/sp.cc
patching file sql/sp_head.cc
patching file sql/sql_parse.cc
patching file sql/sql_table.cc
patching file sql/sql_yacc.yy
OK-patch transferred, enjoy!
$
Source code for the tarball/update clients:
/*
* tarball.c copyright (c) 2003 BitMover, Inc.
*
* Licensed under the NWL - No Whining License.
*
* You may use this, modify this, redistribute this provided you agree:
* - not to whine about this product or any other products from BitMover, Inc.
* - that there is no warranty of any kind.
* - retain this copyright in full.
*/
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <arpa/inet.h>
#define min(x, y) ((x) < (y) ? (x) : (y))
#define unless(x) if (!(x))
/*
* Connect to the TCP socket advertised as "port" on "host" and
* return the connected socket.
*/
int
tcp_connect(char *host, int port)
{
struct hostent *h;
struct sockaddr_in s;
int sock;
if ((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
perror("socket");
return (-1);
}
unless (h = gethostbyname(host)) return (-2);
memset((void *) &s, 0, sizeof(s));
s.sin_family = AF_INET;
memmove((void *)&s.sin_addr, (void*)h->h_addr, h->h_length);
s.sin_port = htons(port);
if (connect(sock, (struct sockaddr*)&s, sizeof(s)) < 0) {
return (-3);
}
return (sock);
}
/*
* Get the tarball and unpack it.
*/
int
main(void)
{
int sock = tcp_connect("localhost", 2000);
int n, left, want, i, bytes;
FILE *f;
char buf[BUFSIZ];
unless (write(sock, "tarball\n", 8) == 8) exit(1);
line: for (i = 0; ; i++) {
unless (read(sock, &buf[i], 1) == 1) exit(1);
if (buf[i] == '\n') {
buf[i+1] = 0;
break;
}
}
switch (buf[0]) {
case 'I':
fprintf(stderr, "%s", buf);
goto line;
case 'E':
fprintf(stderr, "%s", buf);
exit(1);
case 'O':
fprintf(stderr, "%s", buf);
sscanf(buf, "OK-tarball coming, %u bytes", &bytes);
left = bytes;
break;
default:
exit(1);
}
system("rm -rf tmp");
mkdir("tmp", 0775);
chdir("tmp");
unless (f = popen("tar xzf -", "w")) exit(1);
want = min(sizeof(buf), left);
while ((n = read(sock, buf, want)) > 0) {
fwrite(buf, 1, n, f);
left -= n;
if (left <= 0) break;
want = min(sizeof(buf), left);
}
pclose(f);
while (read(sock, buf, 1) == 1) write(2, buf, 1);
return (0);
}
/*
* update.c copyright (c) 2003 BitMover, Inc.
*
* Licensed under the NWL - No Whining License.
*
* You may use this, modify this, redistribute this provided you agree:
* - not to whine about this product or any other products from BitMover, Inc.
* - that there is no warranty of any kind.
* - retain this copyright in full.
*/
#include <errno.h>
#include <zlib.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <arpa/inet.h>
#define min(x, y) ((x) < (y) ? (x) : (y))
#define unless(x) if (!(x))
#define u32 unsigned int
/*
* Connect to the TCP socket advertised as "port" on "host" and
* return the connected socket.
*/
int
tcp_connect(char *host, int port)
{
struct hostent *h;
struct sockaddr_in s;
int sock;
if ((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
perror("socket");
return (-1);
}
unless (h = gethostbyname(host)) return (-2);
memset((void *) &s, 0, sizeof(s));
s.sin_family = AF_INET;
memmove((void *)&s.sin_addr, (void*)h->h_addr, h->h_length);
s.sin_port = htons(port);
if (connect(sock, (struct sockaddr*)&s, sizeof(s)) < 0) {
return (-3);
}
return (sock);
}
/*
* Get the patch and unpack it.
*/
int
main(void)
{
int sock = tcp_connect("localhost", 2000);
int n, left, want, i;
FILE *f;
char buf[BUFSIZ];
if (chdir("tmp")) exit(1);
unless (write(sock, "patch\n", 6) == 6) exit(1);
unless (f = fopen("BitKeeper/etc/keys", "r")) exit(1);
while (fgets(buf, sizeof(buf), f)) {
if (write(sock, buf, strlen(buf)) != strlen(buf)) exit(1);
}
fclose(f);
line: for (i = 0; ; i++) {
unless (read(sock, &buf[i], 1) == 1) exit(1);
if (buf[i] == '\n') {
buf[i+1] = 0;
break;
}
}
switch (buf[0]) {
case 'I':
fprintf(stderr, "%s", buf);
goto line;
case 'E':
fprintf(stderr, "%s", buf);
exit(1);
case 'O':
fprintf(stderr, "%s", buf);
sscanf(buf, "OK-patch coming, %u bytes...", &left);
break;
default:
exit(1);
}
unless (f = popen("gunzip | patch -p1", "w")) exit(1);
want = min(sizeof(buf), left);
while ((n = read(sock, buf, want)) > 0) {
fwrite(buf, 1, n, f);
left -= n;
if (left <= 0) break;
want = min(sizeof(buf), left);
}
pclose(f);
while (read(sock, buf, 1) == 1) write(2, buf, 1);
return (0);
}
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: RFC - tarball/patch server in BitKeeper
2003-12-14 17:21 RFC - tarball/patch server in BitKeeper Larry McVoy
@ 2003-12-14 23:05 ` Keith Owens
2003-12-14 23:44 ` Larry McVoy
2003-12-14 23:17 ` Tupshin Harper
` (3 subsequent siblings)
4 siblings, 1 reply; 35+ messages in thread
From: Keith Owens @ 2003-12-14 23:05 UTC (permalink / raw)
To: Larry McVoy; +Cc: linux-kernel, bitkeeper-users
On Sun, 14 Dec 2003 09:21:56 -0800,
Larry McVoy <lm@bitmover.com> wrote:
>I've prototyped an extension to BitKeeper that provides tarballs
>and patches. ...
>... You need to understand that this is all you get,
>we're not going to extend this so you can do anything but track the most
>recent sources accurately. No diffs. No getting anything but the most
>recent version. No revision history.
Do we get the changelogs from each BK check in? Without the
changelogs, patches are going to be much less useful.
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: RFC - tarball/patch server in BitKeeper
2003-12-14 23:05 ` Keith Owens
@ 2003-12-14 23:44 ` Larry McVoy
2003-12-15 0:25 ` Keith Owens
0 siblings, 1 reply; 35+ messages in thread
From: Larry McVoy @ 2003-12-14 23:44 UTC (permalink / raw)
To: Keith Owens; +Cc: Larry McVoy, linux-kernel, bitkeeper-users
On Mon, Dec 15, 2003 at 10:05:03AM +1100, Keith Owens wrote:
> On Sun, 14 Dec 2003 09:21:56 -0800,
> Larry McVoy <lm@bitmover.com> wrote:
> >I've prototyped an extension to BitKeeper that provides tarballs
> >and patches. ...
> >... You need to understand that this is all you get,
> >we're not going to extend this so you can do anything but track the most
> >recent sources accurately. No diffs. No getting anything but the most
> >recent version. No revision history.
>
> Do we get the changelogs from each BK check in? Without the
> changelogs, patches are going to be much less useful.
You already get those, use BK/Web. It's all there and always has been.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-14 23:44 ` Larry McVoy
@ 2003-12-15 0:25 ` Keith Owens
2003-12-15 3:47 ` Larry McVoy
0 siblings, 1 reply; 35+ messages in thread
From: Keith Owens @ 2003-12-15 0:25 UTC (permalink / raw)
To: Larry McVoy; +Cc: linux-kernel, bitkeeper-users
On Sun, 14 Dec 2003 15:44:23 -0800,
Larry McVoy <lm@bitmover.com> wrote:
>On Mon, Dec 15, 2003 at 10:05:03AM +1100, Keith Owens wrote:
>> On Sun, 14 Dec 2003 09:21:56 -0800,
>> Larry McVoy <lm@bitmover.com> wrote:
>> >I've prototyped an extension to BitKeeper that provides tarballs
>> >and patches. ...
>> >... You need to understand that this is all you get,
>> >we're not going to extend this so you can do anything but track the most
>> >recent sources accurately. No diffs. No getting anything but the most
>> >recent version. No revision history.
>>
>> Do we get the changelogs from each BK check in? Without the
>> changelogs, patches are going to be much less useful.
>
>You already get those, use BK/Web. It's all there and always has been.
Using update and BK/Web means manually reconciling two sets of data
which may have different time bases. If update has not been run for 23
days, the user has to look at "Changesets in the last four weeks" and
manually determine where in that log of 119 changesets (linux-2.5)
their last update was done before they know which changesets are in the
current update.
What about this, assuming it does not give away information that you
believe will be used for $SCM. Treat the BK changelog as a file, and
have update generate a patch from the last update for the changelog as
well as the project files.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 0:25 ` Keith Owens
@ 2003-12-15 3:47 ` Larry McVoy
0 siblings, 0 replies; 35+ messages in thread
From: Larry McVoy @ 2003-12-15 3:47 UTC (permalink / raw)
To: Keith Owens; +Cc: Larry McVoy, linux-kernel, bitkeeper-users
On Mon, Dec 15, 2003 at 11:25:11AM +1100, Keith Owens wrote:
> On Sun, 14 Dec 2003 15:44:23 -0800,
> Larry McVoy <lm@bitmover.com> wrote:
> >On Mon, Dec 15, 2003 at 10:05:03AM +1100, Keith Owens wrote:
> >> On Sun, 14 Dec 2003 09:21:56 -0800,
> >> Larry McVoy <lm@bitmover.com> wrote:
> >> >I've prototyped an extension to BitKeeper that provides tarballs
> >> >and patches. ...
> >> >... You need to understand that this is all you get,
> >> >we're not going to extend this so you can do anything but track the most
> >> >recent sources accurately. No diffs. No getting anything but the most
> >> >recent version. No revision history.
> >>
> >> Do we get the changelogs from each BK check in? Without the
> >> changelogs, patches are going to be much less useful.
> >
> >You already get those, use BK/Web. It's all there and always has been.
>
> Using update and BK/Web means manually reconciling two sets of data
> which may have different time bases. If update has not been run for 23
> days, the user has to look at "Changesets in the last four weeks" and
> manually determine where in that log of 119 changesets (linux-2.5)
> their last update was done before they know which changesets are in the
> current update.
>
> What about this, assuming it does not give away information that you
> believe will be used for $SCM. Treat the BK changelog as a file, and
> have update generate a patch from the last update for the changelog as
> well as the project files.
That would be what the BK2CVS export does. It's perfect for what you want,
use it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-14 17:21 RFC - tarball/patch server in BitKeeper Larry McVoy
2003-12-14 23:05 ` Keith Owens
@ 2003-12-14 23:17 ` Tupshin Harper
2003-12-14 23:43 ` Larry McVoy
2003-12-15 6:31 ` Martin J. Bligh
` (2 subsequent siblings)
4 siblings, 1 reply; 35+ messages in thread
From: Tupshin Harper @ 2003-12-14 23:17 UTC (permalink / raw)
To: Larry McVoy; +Cc: linux-kernel, bitkeeper-users
Larry McVoy wrote:
>Merry Christmas.
>
>I've prototyped an extension to BitKeeper that provides tarballs
>and patches. The idea is to make it possible for all trees hosted by
>bkbits.net provide access to the data with a free client (included below
>in prototype form).
>
>The system is simplistic, it just provides a way to get the most recent
>sources as a tarball and then any later updates as a patch. There is
>no provision for generating diffs, editing files, merging, etc. All of
>that is something that you can write, if you want, using standard tools
>(think hard linked trees).
>
>Before rolling this out, I want to know if this is going to (finally)
>put to rest any complaints about BK not being open source, available on
>all platforms, etc. You need to understand that this is all you get,
>we're not going to extend this so you can do anything but track the most
>recent sources accurately. No diffs. No getting anything but the most
>recent version. No revision history.
>
>If you want anything other than the most recent version your choices
>are to use BitKeeper itself or, if you want the main branches of the
>Linux kernel, the BK2CVS exports. This is not a gateway product, it
>is a way for developers to track the latest and greatest with a free
>(source based) client. It is not a way to convert BK repos to $SCM.
>
>If the overwhelming response is positive then I'll add this to the
>bkbits.net server and perhaps eventually to the BK product itself.
>
>--lm
>
I'm sure many people will find this useful. Personally (and this is not
intended as any sort of flame bait), I just want a way to get access to
all raw bk changesets for a given project. All existing methods of
getting information out of a bk repository either involve running bk
yourself, or getting incomplete information. You have argued
(succesfully) that the CVS export doesn't lose very much information,
but an argument can be made that any information loss is too much. After
all, the information I am talking about is simply what was put into the
system by the developers in the first place.
-Tupshin
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: RFC - tarball/patch server in BitKeeper
2003-12-14 23:17 ` Tupshin Harper
@ 2003-12-14 23:43 ` Larry McVoy
2003-12-15 0:19 ` Tupshin Harper
0 siblings, 1 reply; 35+ messages in thread
From: Larry McVoy @ 2003-12-14 23:43 UTC (permalink / raw)
To: Tupshin Harper; +Cc: linux-kernel
On Sun, Dec 14, 2003 at 03:17:04PM -0800, Tupshin Harper wrote:
> I'm sure many people will find this useful. Personally (and this is not
> intended as any sort of flame bait), I just want a way to get access to
> all raw bk changesets for a given project.
I'm sure you do, I've read your postings on various SCM mailing lists.
You'll have to get your test data elsewhere, sorry, we're not in the
business of helping you develop a competing product. Using BK to do
that is a violation of the free use license and I'm sure you are aware
of that.
> All existing methods of
> getting information out of a bk repository either involve running bk
> yourself, or getting incomplete information. You have argued
> (succesfully) that the CVS export doesn't lose very much information,
> but an argument can be made that any information loss is too much. After
> all, the information I am talking about is simply what was put into the
> system by the developers in the first place.
Nonsense! It's the information put in there by BitKeeper. The BK2CVS
export is an almost perfect mirror of what you'd get if the developers
were using CVS or Subversion or whatever.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-14 23:43 ` Larry McVoy
@ 2003-12-15 0:19 ` Tupshin Harper
2003-12-15 3:46 ` Larry McVoy
0 siblings, 1 reply; 35+ messages in thread
From: Tupshin Harper @ 2003-12-15 0:19 UTC (permalink / raw)
To: Larry McVoy; +Cc: linux-kernel
Larry McVoy wrote:
>On Sun, Dec 14, 2003 at 03:17:04PM -0800, Tupshin Harper wrote:
>
>
>>I'm sure many people will find this useful. Personally (and this is not
>>intended as any sort of flame bait), I just want a way to get access to
>>all raw bk changesets for a given project.
>>
>>
>
>I'm sure you do, I've read your postings on various SCM mailing lists.
>You'll have to get your test data elsewhere, sorry, we're not in the
>business of helping you develop a competing product. Using BK to do
>that is a violation of the free use license and I'm sure you are aware
>of that.
>
>
Of course...that's the only reason why it's an issue.
>
>
>>All existing methods of
>>getting information out of a bk repository either involve running bk
>>yourself, or getting incomplete information. You have argued
>>(succesfully) that the CVS export doesn't lose very much information,
>>but an argument can be made that any information loss is too much. After
>>all, the information I am talking about is simply what was put into the
>>system by the developers in the first place.
>>
>>
>
>Nonsense! It's the information put in there by BitKeeper. The BK2CVS
>export is an almost perfect mirror of what you'd get if the developers
>were using CVS or Subversion or whatever.
>
>
What are are effectively doing, then, is creating vendor lock-in based
on file format...a very Microsoftian approach. You are encouraging
developers to adopt your tool, but then telling them that if they ever
want to adopt a different tool, then they will have to forego using some
of the information that they created using your tool. So the decision of
which tool to be used becomes based on pain of switching, and not based
on technical merit. Hmmm.
-Tupshin
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 0:19 ` Tupshin Harper
@ 2003-12-15 3:46 ` Larry McVoy
2003-12-15 6:07 ` Tupshin Harper
0 siblings, 1 reply; 35+ messages in thread
From: Larry McVoy @ 2003-12-15 3:46 UTC (permalink / raw)
To: Tupshin Harper; +Cc: Larry McVoy, linux-kernel
On Sun, Dec 14, 2003 at 04:19:35PM -0800, Tupshin Harper wrote:
> >I'm sure you do, I've read your postings on various SCM mailing lists.
> >You'll have to get your test data elsewhere, sorry, we're not in the
> >business of helping you develop a competing product. Using BK to do
> >that is a violation of the free use license and I'm sure you are aware
> >of that.
> >
> Of course...that's the only reason why it's an issue.
Great, glad you understand that you are crossing the legal line.
> What are are effectively doing, then, is creating vendor lock-in based
> on file format...a very Microsoftian approach. You are encouraging
> developers to adopt your tool, but then telling them that if they ever
> want to adopt a different tool, then they will have to forego using some
> of the information that they created using your tool. So the decision of
> which tool to be used becomes based on pain of switching, and not based
> on technical merit. Hmmm.
What a pile of nonsense. Let's translate this to reality. You can't
figure out how to build the right answer and you have decided you need
access to internal information created by BitKeeper to reverse engineer
BitKeeper and you are complaining because we don't feel obligated to
give you that.
If you think you can create a better answer on your own, by all means,
do so, nobody is stopping you. But whining that you aren't being helped
by the people who have figured it out is not exactly inspiring. I can
assure you that I am not inspired to help you and I'm disgusted that yet
again an you have taken something that we are trying to do to help people
and turned it into a whine fest for your personal agenda.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 3:46 ` Larry McVoy
@ 2003-12-15 6:07 ` Tupshin Harper
2003-12-15 16:02 ` Larry McVoy
0 siblings, 1 reply; 35+ messages in thread
From: Tupshin Harper @ 2003-12-15 6:07 UTC (permalink / raw)
To: Larry McVoy; +Cc: linux-kernel
Larry McVoy wrote:
> On Sun, Dec 14, 2003 at 04:19:35PM -0800, Tupshin Harper wrote:
>
>>> I'm sure you do, I've read your postings on various SCM mailing
>>> lists. You'll have to get your test data elsewhere, sorry,
>>> we're not in the business of helping you develop a competing
>>> product. Using BK to do that is a violation of the free use
>>> license and I'm sure you are aware of that.
>>>
>> Of course...that's the only reason why it's an issue.
>
>
> Great, glad you understand that you are crossing the legal line.
??? what line am I crossing? Or do you mean that I would be if I were
to do something, and if so, what is that something? I informed you the
day that decided I was interested in exploring the internals of other
SCM products, and deleted the bk binaries from my machine at the same
time.
>
>> What are are effectively doing, then, is creating vendor lock-in
>> based on file format...a very Microsoftian approach. You are
>> encouraging developers to adopt your tool, but then telling them
>> that if they ever want to adopt a different tool, then they will
>> have to forego using some of the information that they created
>> using your tool. So the decision of which tool to be used becomes
>> based on pain of switching, and not based on technical merit.
>> Hmmm.
>
>
> What a pile of nonsense. Let's translate this to reality. You
> can't figure out how to build the right answer and you have decided
> you need access to internal information created by BitKeeper to
> reverse engineer BitKeeper and you are complaining because we don't
> feel obligated to give you that.
That's nonsense. There are plenty of bk changesets that I could
download from numerous public sources. They would provide just as much
information about bk internals as any other bk changesets. There are
complete (non-Linus) linux trees available in changeset form. If
reverse engineering were my goal, then those would be sufficient. The
question is one of ownership. Does bitmover own the changeset or does
the developer own the changeset?
> If you think you can create a better answer on your own, by all
> means, do so, nobody is stopping you. But whining that you aren't
> being helped by the people who have figured it out is not exactly
> inspiring. I can assure you that I am not inspired to help you and
> I'm disgusted that yet again an you have taken something that we
> are trying to do to help people and turned it into a whine fest for
> your personal agenda.
You specifically asked if it would address people's issues. I could
only speak for myself...and I did.
-Tupshin
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 6:07 ` Tupshin Harper
@ 2003-12-15 16:02 ` Larry McVoy
2003-12-15 19:52 ` Tupshin Harper
0 siblings, 1 reply; 35+ messages in thread
From: Larry McVoy @ 2003-12-15 16:02 UTC (permalink / raw)
To: Tupshin Harper; +Cc: Larry McVoy, linux-kernel
On Sun, Dec 14, 2003 at 10:07:46PM -0800, Tupshin Harper wrote:
> > Great, glad you understand that you are crossing the legal line.
>
> ??? what line am I crossing? Or do you mean that I would be if I were
> to do something, and if so, what is that something? I informed you the
> day that decided I was interested in exploring the internals of other
> SCM products, and deleted the bk binaries from my machine at the same
> time.
Tupshin, the BK license makes it clear that BK doesn't want to be reverse
engineered, we've been over this and over this. Furthermore, reverse
engineering for interoperability has a prerequisite that there is no other
way to get at the data and we give you tons of ways to get at the data.
You keep wanting more and more information about how BitKeeper manages
to do what it does and that certainly falls under reverse engineering.
Getting at the raw information is just another way to figure out how
BitKeeper manages that data, it's exactly the same as running a compiler
and looking at the assembly language it produces. You are annoyed that
we aren't giving you the data in the format you want with a roadmap that
says here is how we did it.
I wish you'd just drop it, this isn't the place to have this discussion,
every time we do anything to help the people who are actually doing kernel
development you or someone like you feels obligated to whine about BK one
more time because of your personal agenda which has nothing to do with
kernel development.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 16:02 ` Larry McVoy
@ 2003-12-15 19:52 ` Tupshin Harper
0 siblings, 0 replies; 35+ messages in thread
From: Tupshin Harper @ 2003-12-15 19:52 UTC (permalink / raw)
To: Larry McVoy; +Cc: linux-kernel
Larry McVoy wrote:
>On Sun, Dec 14, 2003 at 10:07:46PM -0800, Tupshin Harper wrote:
>
>
>>>Great, glad you understand that you are crossing the legal line.
>>>
>>>
>>??? what line am I crossing? Or do you mean that I would be if I were
>>to do something, and if so, what is that something? I informed you the
>>day that decided I was interested in exploring the internals of other
>>SCM products, and deleted the bk binaries from my machine at the same
>>time.
>>
>>
>Tupshin, the BK license makes it clear that BK doesn't want to be reverse
>engineered, we've been over this and over this. Furthermore, reverse
>engineering for interoperability has a prerequisite that there is no other
>way to get at the data and we give you tons of ways to get at the data.
>
>
But not all data. That's the point. The bk2cvs process is lossy...you
can't gloss over that point.
>You keep wanting more and more information about how BitKeeper manages
>to do what it does and that certainly falls under reverse engineering.
>
>
No...I keep wanting free (speech) access to all (current and historical
information) that is part of the kernel. You ignored the question of who
owns the changesets. Or maybe, more appropriately, what license do the
changesets have?
>Getting at the raw information is just another way to figure out how
>BitKeeper manages that data, it's exactly the same as running a compiler
>and looking at the assembly language it produces.
>
Is there some implication here that is a license violation for a bk
(free license) user to make available full changesets for non-bk users
to user for *any* purpose?
-Tupshin
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-14 17:21 RFC - tarball/patch server in BitKeeper Larry McVoy
2003-12-14 23:05 ` Keith Owens
2003-12-14 23:17 ` Tupshin Harper
@ 2003-12-15 6:31 ` Martin J. Bligh
2003-12-15 12:11 ` Sergey Vlasov
2003-12-15 15:42 ` Larry McVoy
2003-12-15 23:18 ` Chris Frey
2003-12-21 20:02 ` Pavel Machek
4 siblings, 2 replies; 35+ messages in thread
From: Martin J. Bligh @ 2003-12-15 6:31 UTC (permalink / raw)
To: Larry McVoy, linux-kernel; +Cc: bitkeeper-users
> I've prototyped an extension to BitKeeper that provides tarballs
> and patches. The idea is to make it possible for all trees hosted by
> bkbits.net provide access to the data with a free client (included below
> in prototype form).
>
> The system is simplistic, it just provides a way to get the most recent
> sources as a tarball and then any later updates as a patch. There is
> no provision for generating diffs, editing files, merging, etc. All of
> that is something that you can write, if you want, using standard tools
> (think hard linked trees).
>
> Before rolling this out, I want to know if this is going to (finally)
> put to rest any complaints about BK not being open source, available on
> all platforms, etc. You need to understand that this is all you get,
> we're not going to extend this so you can do anything but track the most
> recent sources accurately. No diffs. No getting anything but the most
> recent version. No revision history.
>
> If you want anything other than the most recent version your choices
> are to use BitKeeper itself or, if you want the main branches of the
> Linux kernel, the BK2CVS exports. This is not a gateway product, it
> is a way for developers to track the latest and greatest with a free
> (source based) client. It is not a way to convert BK repos to $SCM.
>
> If the overwhelming response is positive then I'll add this to the
> bkbits.net server and perhaps eventually to the BK product itself.
That looks very cool to me at least - I'd find it helpful, I think.
Thank you.
One thing that I've wished for in the past which looks like it *might*
be trivial to do is to grab a raw version of the patch you already
put out in HTML format, eg if I surf down changesets and get to a page
like this:
http://linus.bkbits.net:8080/linux-2.5/patch@1.1522?nav=index.html|ChangeSet@-2w|cset@1.1522
except it got html formatted, so I can't play with it easily. Is there
any way to provide the raw format of that? If not, or you don't want to,
no problem - would just be convenient. This isn't a open source vs not
issue, it's just I often want one fix without the whole tree, and it'd
be a convenient place to grab it.
> * Licensed under the NWL - No Whining License.
> *
> * You may use this, modify this, redistribute this provided you agree:
> * - not to whine about this product or any other products from BitMover, Inc.
> * - that there is no warranty of any kind.
> * - retain this copyright in full.
;-)
M.
PS. If you could possibly generate the diffs with -p, whether you supply
them in raw format or not, it'd make them easier to read.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 6:31 ` Martin J. Bligh
@ 2003-12-15 12:11 ` Sergey Vlasov
2003-12-15 13:27 ` Ben Collins
2003-12-15 15:42 ` Larry McVoy
1 sibling, 1 reply; 35+ messages in thread
From: Sergey Vlasov @ 2003-12-15 12:11 UTC (permalink / raw)
To: linux-kernel; +Cc: bitkeeper-users
On Sun, 14 Dec 2003 22:31:04 -0800 Martin J. Bligh wrote:
> One thing that I've wished for in the past which looks like it *might*
> be trivial to do is to grab a raw version of the patch you already
> put out in HTML format, eg if I surf down changesets and get to a page
> like this:
>
> http://linus.bkbits.net:8080/linux-2.5/patch@1.1522?nav=index.html|ChangeSet@-2w|cset@1.1522
>
> except it got html formatted, so I can't play with it easily. Is there
> any way to provide the raw format of that? If not, or you don't want to,
> no problem - would just be convenient. This isn't a open source vs not
> issue, it's just I often want one fix without the whole tree, and it'd
> be a convenient place to grab it.
You almost can do this now - in most cases, copying the text from
Mozilla gives a good patch. The only problem is that the HTML
generation code seems to have a bug - it correctly escapes '<' as
"<" and '>' as ">", but does not escape '&' as "&", and this
occasionally leads to problems.
I see another missing feature - there does not seem to be a way to
order the changesets by the order of merging them into the tree. E.g.
when you look at the linux-2.4 changesets, you will now find XFS all
over the place - even before 2.4.23, while it really has been merged
after 2.4.23.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 12:11 ` Sergey Vlasov
@ 2003-12-15 13:27 ` Ben Collins
2003-12-15 16:24 ` Sergey Vlasov
0 siblings, 1 reply; 35+ messages in thread
From: Ben Collins @ 2003-12-15 13:27 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: linux-kernel, bitkeeper-users
On Mon, Dec 15, 2003 at 03:11:26PM +0300, Sergey Vlasov wrote:
> On Sun, 14 Dec 2003 22:31:04 -0800 Martin J. Bligh wrote:
>
> > One thing that I've wished for in the past which looks like it *might*
> > be trivial to do is to grab a raw version of the patch you already
> > put out in HTML format, eg if I surf down changesets and get to a page
> > like this:
> >
> > http://linus.bkbits.net:8080/linux-2.5/patch@1.1522?nav=index.html|ChangeSet@-2w|cset@1.1522
> >
> > except it got html formatted, so I can't play with it easily. Is there
> > any way to provide the raw format of that? If not, or you don't want to,
> > no problem - would just be convenient. This isn't a open source vs not
> > issue, it's just I often want one fix without the whole tree, and it'd
> > be a convenient place to grab it.
>
> You almost can do this now - in most cases, copying the text from
> Mozilla gives a good patch. The only problem is that the HTML
> generation code seems to have a bug - it correctly escapes '<' as
> "<" and '>' as ">", but does not escape '&' as "&", and this
> occasionally leads to problems.
>
> I see another missing feature - there does not seem to be a way to
> order the changesets by the order of merging them into the tree. E.g.
> when you look at the linux-2.4 changesets, you will now find XFS all
> over the place - even before 2.4.23, while it really has been merged
> after 2.4.23.
You don't seem to understand how bitkeeper works then. Back when the XFS
tree was cloned from the 2.4 tree, it began it's own "branch". Over time
it has merged code from the 2.4 tree, and it's work has occured over
this same time.
When XFS was merged back into the 2.4 tree, it retains all of that
history in sort of a split road looking branch/merge.
You wont be able to get an "XFS changeset".
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 13:27 ` Ben Collins
@ 2003-12-15 16:24 ` Sergey Vlasov
2003-12-15 16:32 ` Larry McVoy
2003-12-15 18:31 ` Andrea Arcangeli
0 siblings, 2 replies; 35+ messages in thread
From: Sergey Vlasov @ 2003-12-15 16:24 UTC (permalink / raw)
To: linux-kernel; +Cc: bitkeeper-users
On Mon, 15 Dec 2003 08:27:20 -0500 Ben Collins wrote:
> On Mon, Dec 15, 2003 at 03:11:26PM +0300, Sergey Vlasov wrote:
> > I see another missing feature - there does not seem to be a way to
> > order the changesets by the order of merging them into the tree. E.g.
> > when you look at the linux-2.4 changesets, you will now find XFS all
> > over the place - even before 2.4.23, while it really has been merged
> > after 2.4.23.
>
> You don't seem to understand how bitkeeper works then. Back when the XFS
> tree was cloned from the 2.4 tree, it began it's own "branch". Over time
> it has merged code from the 2.4 tree, and it's work has occured over
> this same time.
>
> When XFS was merged back into the 2.4 tree, it retains all of that
> history in sort of a split road looking branch/merge.
Keeping that history is good. But the main 2.4 branch also has its own
history - and it shows that there were no XFS code in that branch up
to and including 2.4.23.
There does not seem to be a way to get this information - at least
through bkbits.net.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 16:24 ` Sergey Vlasov
@ 2003-12-15 16:32 ` Larry McVoy
2003-12-15 18:31 ` Andrea Arcangeli
1 sibling, 0 replies; 35+ messages in thread
From: Larry McVoy @ 2003-12-15 16:32 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: linux-kernel, bitkeeper-users
On Mon, Dec 15, 2003 at 07:24:02PM +0300, Sergey Vlasov wrote:
> On Mon, 15 Dec 2003 08:27:20 -0500 Ben Collins wrote:
> Keeping that history is good. But the main 2.4 branch also has its own
> history - and it shows that there were no XFS code in that branch up
> to and including 2.4.23.
>
> There does not seem to be a way to get this information - at least
> through bkbits.net.
There isn't, someone would need to come up with a good graph drawing alg that
works in a web browser. We tried java and it sucked.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 16:24 ` Sergey Vlasov
2003-12-15 16:32 ` Larry McVoy
@ 2003-12-15 18:31 ` Andrea Arcangeli
2003-12-15 18:58 ` Larry McVoy
1 sibling, 1 reply; 35+ messages in thread
From: Andrea Arcangeli @ 2003-12-15 18:31 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: linux-kernel
On Mon, Dec 15, 2003 at 07:24:02PM +0300, Sergey Vlasov wrote:
> On Mon, 15 Dec 2003 08:27:20 -0500 Ben Collins wrote:
>
> > On Mon, Dec 15, 2003 at 03:11:26PM +0300, Sergey Vlasov wrote:
> > > I see another missing feature - there does not seem to be a way to
> > > order the changesets by the order of merging them into the tree. E.g.
> > > when you look at the linux-2.4 changesets, you will now find XFS all
> > > over the place - even before 2.4.23, while it really has been merged
> > > after 2.4.23.
> >
> > You don't seem to understand how bitkeeper works then. Back when the XFS
> > tree was cloned from the 2.4 tree, it began it's own "branch". Over time
> > it has merged code from the 2.4 tree, and it's work has occured over
> > this same time.
> >
> > When XFS was merged back into the 2.4 tree, it retains all of that
> > history in sort of a split road looking branch/merge.
>
> Keeping that history is good. But the main 2.4 branch also has its own
> history - and it shows that there were no XFS code in that branch up
> to and including 2.4.23.
>
> There does not seem to be a way to get this information - at least
> through bkbits.net.
you get the 2.4 branch linear history via bkcvs. Though there you lose
all the granular xfs development changesets instead, the xfs merge
becames a huge monolithic patch see below. Either way or another you
lose information compared to true BK. From my part I'm fine with the
info provided in bkcvs, I'm only correcting Larry statement about him
providing lots of way to get at the data in a interoperable protocol,
he's only providing _partial_ data in a interoperable way. I'm stating
facts, no whining intendend.
---------------------
PatchSet 4315
Date: 2003/12/08 10:56:10
Author: marcelo
Branch: HEAD
Tag: (none)
Log:
Merge http://xfs.org:8090/linux-2.4+justXFS
into logos.cnet:/home/marcelo/bk/linux-2.4
2003/12/07 18:05:50-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/music/bkroot/linux-2.4+justXFS
2003/12/07 12:05:42-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/music/bkroot/linux-2.4+justXFS
2003/12/07 10:06:25-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/music/bkroot/linux-2.4+justXFS
2003/12/07 06:12:25-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/music/bkroot/linux-2.4+justXFS
2003/12/06 13:11:32-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/music/bkroot/linux-2.4+justXFS
2003/12/05 09:10:59-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/music/bkroot/linux-2.4+justXFS
2003/12/05 08:10:27-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/music/bkroot/linux-2.4+justXFS
2003/12/05 06:11:17-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/music/bkroot/linux-2.4+justXFS
2003/12/03 22:31:56-06:00 cattelan
Gone dmapi
2003/12/03 08:10:37-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/music/bkroot/linux-2.4+justXFS
2003/12/03 04:09:22-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/music/bkroot/linux-2.4+justXFS
2003/12/03 17:04:05+11:00 nathans
Merge nathans@xfs.org:/export/hose/bkroot/linux-2.4+justXFS
into bruce.melbourne.sgi.com:/source1/linux-2.4+justXFS
2003/12/03 17:01:12+11:00 nathans
[XFS] Fix comment in xfs_rename.c
SGI Modid: xfs-linux:slinx:162760a
2003/12/03 16:56:07+11:00 nathans
[XFS] Prevent log ktrace code from sleeping in an invalid context.
SGI Modid: xfs-linux:slinx:162768a
2003/12/03 16:51:38+11:00 nathans
[XFS] Use vnode timespec modifiers for atime/mtime/ctime, keeps last code hunk in sync.
SGI Modid: xfs-linux:slinx:162782a
2003/12/02 15:29:17-06:00 cattelan
Merge cattelan@xfs.org:/export/hose/bkroot/linux-2.4+justXFS
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/12/02 15:27:16-06:00 cattelan
Merge naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/12/02 12:07:27-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/hose/bkroot/linux-2.4+justXFS
2003/12/02 10:56:27-06:00 cattelan
Merge cattelan@xfs.org:/export/hose/bkroot/linux-2.4+justXFS
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/12/02 10:55:00-06:00 cattelan
Merge naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/12/02 09:10:50-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/hose/bkroot/linux-2.4+justXFS
2003/12/02 08:09:28-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/hose/bkroot/linux-2.4+justXFS
2003/12/01 14:12:40-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/hose/bkroot/linux-2.4+justXFS
2003/12/01 10:59:59-06:00 cattelan
Merge cattelan@xfs.org:/export/hose/bkroot/linux-2.4+justXFS
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/12/01 10:58:16-06:00 cattelan
Merge naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/12/01 10:36:38+11:00 nathans
[XFS] Remove some unused pagebuf source and header files.
2003/12/01 10:21:09+11:00 nathans
[XFS] Add the noikeep mount option, make ikeep the default for now.
SGI Modid: xfs-linux:slinx:162621a
2003/12/01 10:05:21+11:00 nathans
[XFS] Update the way we hook into the generic direct IO code so we share more code. This means we no longer need to dup remove_suid within xfs_write_clear_setuid.
SGI Modid: xfs-linux:slinx:162446a
2003/12/01 09:59:33+11:00 nathans
[XFS] Convert to revised kmem shake interface.
SGI Modid: xfs-linux:slinx:162426a
2003/12/01 09:56:21+11:00 nathans
[XFS] Use a kmem shaking interface for 2.4 which is much more like the 2.6 one.
SGI Modid: xfs-linux:slinx:162377a
2003/11/30 12:06:55-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/hose/bkroot/linux-2.4+justXFS
2003/11/25 15:20:10-06:00 cattelan
Merge lips.borg.umn.edu:/export/hose/bkroot/linux-2.4
into lips.borg.umn.edu:/export/hose/bkroot/linux-2.4+justXFS
2003/11/24 15:08:28-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/24 11:52:28-06:00 cattelan
Merge cattelan@xfs.org:/export/hose/bkroot/linux-2.4+justXFS
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/11/24 11:50:51-06:00 cattelan
Merge naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/11/24 11:42:12-06:00 nathans
[XFS] Fix some incorrect debug code after buftarg changes.
SGI Modid: xfs-linux:slinx:162334a
2003/11/24 11:41:29-06:00 nathans
[XFS] Abstract out the current_time interface use from quota to support multiple kernel versions.
SGI Modid: xfs-linux:slinx:162333a
2003/11/24 11:40:40-06:00 nathans
[XFS] Switch debug quota code to use xfs_buftarg interface instead of dev_t
SGI Modid: xfs-linux:slinx:162332a
2003/11/24 11:39:45-06:00 nathans
[XFS] Use xfs_statfs type to statfs operation, to support multiple kernels more easily.
SGI Modid: xfs-linux:slinx:162330a
2003/11/24 11:38:45-06:00 nathans
[XFS] Abstract sendfile operation out, supporting multiple kernels more easily.
SGI Modid: xfs-linux:slinx:162328a
2003/11/24 11:37:46-06:00 nathans
[XFS] Use iomap abstraction consistently.
SGI Modid: xfs-linux:slinx:162327a
2003/11/24 11:36:05-06:00 nathans
[XFS] Merge find_next_zero_bit casting fixes back from 2.6 code
SGI Modid: xfs-linux:slinx:162321a
2003/11/24 11:35:16-06:00 nathans
[XFS] Switch from using dev_t to xfs_buftarg_t for representing the devices underneath XFS
SGI Modid: xfs-linux:slinx:162319a
2003/11/24 11:34:23-06:00 nathans
[XFS] Move the stack trace wrapper into a kernel-version-specific location.
SGI Modid: xfs-linux:slinx:162318a
2003/11/24 11:05:44-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/24 06:06:26-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/22 08:05:41-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/21 15:50:01-06:00 sandeen
[XFS] Fix the pb stats clear handler, value is
int but handler was using ulong
SGI Modid: xfs-linux:slinx:162287a
2003/11/21 15:49:13-06:00 sandeen
[XFS] Fix a few sysctls - values are all ints, but
sysctl table was setting up for longs.
SGI Modid: xfs-linux:slinx:162285a
2003/11/21 15:27:01-06:00 cattelan
Merge cattelan@xfs.org:/export/hose/bkroot/linux-2.4+justXFS
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/11/21 15:03:14-06:00 cattelan
Merge naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/11/21 14:55:34-06:00 nathans
[XFS] Fix build fallout from refcache reorganisation.
2003/11/21 14:53:54-06:00 nathans
[XFS] Fix a build error in some debug code.
SGI Modid: xfs-linux:slinx:162147a
2003/11/21 14:52:47-06:00 nathans
[XFS] Switch to using the BSD qsort implementation.
SGI Modid: xfs-linux:slinx:162158a
2003/11/21 14:51:07-06:00 nathans
[XFS] Trivial/whitespace changes to sync up different trees a bit.
SGI Modid: xfs-linux:slinx:162244a
2003/11/21 14:46:44-06:00 nathans
[XFS] Change pagebuf to use the same ktrace implementation as XFS, instead of reinventing that wheel.
SGI Modid: xfs-linux:slinx:162159a
2003/11/21 14:45:05-06:00 nathans
[XFS] Merge page_buf_locking routines in with the rest of page_buf.
SGI Modid: xfs-linux:slinx:162155a
2003/11/21 14:39:14-06:00 nathans
[XFS] Remove assertion that we do not hold a lock - no lock ownership state available.
SGI Modid: xfs-linux:slinx:162250a
2003/11/21 14:37:03-06:00 nathans
[XFS] Seperate the NFS reference cache code out from xfs_rw.c to simplify management of different kernel versions.
SGI Modid: xfs-linux:slinx:162241a
2003/11/21 11:05:37-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/20 13:05:37-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/20 10:06:02-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/20 08:05:42-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/19 11:23:27-06:00 cattelan
[XFS] Add new file ... missed in orginal checkin
SGI Modid: xfs-linux:slinx:162050a
2003/11/19 11:22:20-06:00 cattelan
[XFS] move the iomap data structures out of pagebuf
SGI Modid: xfs-linux:slinx:162048a
2003/11/19 11:20:48-06:00 nathans
[XFS] Move Linux-version specific code out of xfs_iomap.c so that it can become part of the XFS core code.
SGI Modid: xfs-linux:slinx:161995a
2003/11/19 11:19:43-06:00 nathans
[XFS] Backport some trivial changes from the 2.6 code base - page uptodate flag macro name changes
SGI Modid: xfs-linux:slinx:161994a
2003/11/19 11:18:38-06:00 nathans
[XFS] Backport an unmerged bug fix from the 2.6 code base - only submit a convert_page page for IO if startio is set.
SGI Modid: xfs-linux:slinx:161993a
2003/11/19 11:17:32-06:00 nathans
[XFS] Backport an unmerged bug fix from the 2.6 code base - if probe_unmapped_page fails while walking down the unmapped page list, do not attempt to probe the last page as well just return.
SGI Modid: xfs-linux:slinx:161992a
2003/11/19 11:16:27-06:00 nathans
[XFS] Backport minor 2.6 changes to the iomap interface to keep code more in sync.
SGI Modid: xfs-linux:slinx:161987a
2003/11/19 11:15:23-06:00 nathans
[XFS] Backport a couple of debugging changes from the 2.6 code base
SGI Modid: xfs-linux:slinx:161984a
2003/11/19 11:14:22-06:00 nathans
[XFS] Enable pagebuf lock tracking via debug.
SGI Modid: xfs-linux:slinx:161981a
2003/11/19 11:12:41-06:00 sandeen
[XFS] BH_Sync added in 2.4.22, put an #ifdef in for now so this
still works on older kernels.
SGI Modid: xfs-linux:slinx:161964a
2003/11/19 11:10:53-06:00 cattelan
Merge rose.americas.sgi.com:/.amd_mnt/naboo/export/space/BKpulls/linux-2.4
into rose.americas.sgi.com:/.amd_mnt/naboo/export/space/BKpulls/linux-2.4+justXFS
2003/11/17 14:25:45-06:00 cattelan
Merge cattelan@xfs.org:/export/hose/bkroot/linux-2.4+justXFS
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/11/17 13:32:57-06:00 sandeen
[XFS] Remove a nested transaction in xfs_dm_punch_hole
SGI Modid: xfs-linux:slinx:161392a
2003/11/17 13:29:55-06:00 sandeen
[XFS] Use buffer head flag set/clear routines as in 2.6
kernel to reduce 2.4/2.6 differences in xfs
SGI Modid: xfs-linux:slinx:161777a
2003/11/17 13:28:35-06:00 sandeen
[XFS] Use i_size_read/i_size_write semantics from 2.6
kernel to reduce 2.4/2.6 differences in xfs
SGI Modid: xfs-linux:slinx:161776a
2003/11/17 13:24:04-06:00 nathans
[XFS] Fix an infinite writepage loop under a combination of low free space, and racing write/unlink calls to the same file.
SGI Modid: xfs-linux:slinx:161773a
2003/11/17 13:00:32-06:00 nathans
[XFS] Fix sign on a pagebuf error variable, backport from 2.6 tree
SGI Modid: xfs-linux:slinx:161708a
2003/11/17 12:59:34-06:00 nathans
[XFS] Remove some spurious 2.4/2.6 differences in support code
SGI Modid: xfs-linux:slinx:161707a
2003/11/17 12:05:40-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/15 11:05:29-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/15 08:05:34-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/14 10:05:54-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/14 09:05:46-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/13 07:05:50-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/13 05:06:30-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/11 12:05:50-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/11 11:13:25-06:00 cattelan
Merge cattelan@xfs.org:/export/hose/bkroot/linux-2.4+justXFS
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/11/11 10:59:22-06:00 nathans
[XFS] Fix a deadlock while writing when low on free space.
SGI Modid: xfs-linux:slinx:161506a
2003/11/10 17:02:57-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/10 05:02:52-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/06 19:02:50-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/06 11:02:54-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/05 15:19:24-06:00 cattelan
Merge cattelan@xfs.org:/export/hose/bkroot/linux-2.4+justXFS/
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/11/05 15:18:48-06:00 roehrich
[XFS] dm_path_to_handle returns errnos with sign flipped.
SGI Modid: xfs-linux:slinx:161149a
2003/11/05 15:17:28-06:00 nathans
[XFS] Fix a supplemental issue introduced by the last small blocksize locking fix; this would manifest itself as a second unlock_page call on an already unlocked page.
SGI Modid: xfs-linux:slinx:160901a
2003/11/05 15:16:27-06:00 sandeen
[XFS] Fix test for large sector_t when finding max file offset
SGI Modid: xfs-linux:slinx:160900a
2003/11/05 15:15:12-06:00 sandeen
[XFS] Add a stack trace to _xfs_force_shutdown.
SGI Modid: xfs-linux:slinx:160899a
2003/11/05 06:04:41-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/04 07:02:49-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/04 05:02:47-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/11/03 11:03:36-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/10/30 16:06:08-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/10/30 10:05:58-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/10/29 18:05:41-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/10/29 14:25:16-06:00 cattelan
Merge cattelan@xfs.org:/export/hose/bkroot/linux-2.4+justXFS/
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/10/29 14:14:23-06:00 nathans
[XFS] Fix pagebuf page locking problems for blocksizes smaller than the pagesize.
SGI Modid: xfs-linux:slinx:160795a
2003/10/29 14:13:01-06:00 nathans
[XFS] Fix warnings when tracing enabled on 64 bit platforms
SGI Modid: xfs-linux:slinx:160622a
2003/10/29 12:57:18-06:00 nathans
[XFS] Dump the pagebuf locked field for debugging purposes
SGI Modid: xfs-linux:slinx:160616a
2003/10/29 12:56:33-06:00 roehrich
[XFS] Remove duplicate FILP_DELAY_FLAG macro
SGI Modid: xfs-linux:slinx:160503a
2003/10/29 12:55:47-06:00 nathans
[XFS] Dont build objects which are not linked into the kernel ever.
SGI Modid: xfs-linux:slinx:160314a
2003/10/29 12:55:03-06:00 nathans
[XFS] Fix compiler warning when building on 2.4.21 kernels.
2003/10/29 12:54:01-06:00 nathans
[XFS] Fix compile warning on 64 bit platforms.
SGI Modid: xfs-linux:slinx:160312a
2003/10/29 12:53:07-06:00 nathans
[XFS] Enable the tracing options in XFS Makefiles.
SGI Modid: xfs-linux:slinx:160246a
2003/10/29 12:52:08-06:00 nathans
[XFS] Fix build with tracing enabled, couple of portability macros, move externs into headers.
SGI Modid: xfs-linux:slinx:160245a
2003/10/29 12:51:05-06:00 nathans
[XFS] When tracing extended attribute calls, only access the buffer when it exists.
SGI Modid: xfs-linux:slinx:160244a
2003/10/29 12:50:15-06:00 nathans
[XFS] Fix exports for tracing symbol access in idbg code.
2003/10/29 12:49:11-06:00 nathans
[XFS] Enable tracing in the quota code if requested
SGI Modid: xfs-linux:slinx:160242a
2003/10/29 12:48:29-06:00 nathans
[XFS] Rename the vnode tracing macro to be consistent with the other trace code
2003/10/29 12:47:20-06:00 nathans
[XFS] Fix build fallout from reordering xfsidbg headers for tracing fixes.
SGI Modid: xfs-linux:slinx:160225a
2003/10/29 12:46:37-06:00 nathans
[XFS] Add back xfsidbg tracing code, remove ktrace<->debug dependency.
SGI Modid: xfs-linux:slinx:160219a
2003/10/29 12:45:55-06:00 nathans
[XFS] Fix log tracing code so it is independent of DEBUG like other traces.
SGI Modid: xfs-linux:slinx:160178a
2003/10/29 12:45:07-06:00 nathans
[XFS] Fix ktrace code - dont build unilaterally, and do earlier init for pagebuf use.
SGI Modid: xfs-linux:slinx:160172a
2003/10/29 12:44:15-06:00 nathans
[XFS] Add some IO path tracing, move inval_cached_pages to a better home to help.
SGI Modid: xfs-linux:slinx:160171a
2003/10/29 12:43:18-06:00 roehrich
[XFS] Implement dm_get_bulkall
SGI Modid: xfs-linux:slinx:159760a
2003/10/29 12:42:25-06:00 nathans
[XFS] Fix inode btree lookup code precision problem with large allocation groups
SGI Modid: xfs-linux:slinx:160092a
2003/10/29 12:41:35-06:00 nathans
[XFS] final round of code cleanup, now using 3-clause-bsd in these headers
SGI Modid: xfs-linux:slinx:159997a
2003/10/29 12:40:50-06:00 nathans
[XFS] Use an xfs_ino_t to hold the result of inode extraction from a handle, not a possibly 32-bit number
2003/10/29 12:39:41-06:00 overby
[XFS] xfs_dir2_node_addname_int had reminants of an old block placement
algorithm in it. The old algorithm appeared to look for the first
place to put a new data block, and thus a new freespace block (this is
where the 'foundindex' variable came from). However, new space in a
directory is always added at the lowest file offset as determined by
the extent list. So this stuff is never used.
I completely ripped out the reminants of the old algorithm, and
(again) moved the freespace block add code inside the conditional
where a data block is added.
SGI Modid: xfs-linux:slinx:159751a
2003/10/29 12:37:50-06:00 nathans
[XFS] Fix compiler warning after change to xfs_ioctl interface.
SGI Modid: xfs-linux:slinx:159720a
2003/10/29 12:36:52-06:00 nathans
[XFS] Rename pagebuf debug option (ie. pagebuf tracing) into a generic XFS tracing option for the other XFS trace code to use too (once fixed).
SGI Modid: xfs-linux:slinx:159717a
2003/10/29 12:34:37-06:00 overby
[XFS] A problem was found with the debug code in xlog_state_do_callback. At
the end of processing all log buffers that can be processed, there is
a (debug only) double-check to make sure that log buffers with
completed I/O don't get marooned when the function completes. The
check only needs to go to the first buffer that will cause an I/O
completion, that has not completed. The loop doesn't stop a WANT_SYNC
state buffer is found, but it should.
SGI Modid: xfs-linux:slinx:159683a
2003/10/29 07:05:44-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/10/28 23:28:26-06:00 lord
[XFS] remove FINVIS from xfs, instead use a seperate file ops
vector for files which are opened for invisible I/O.
SGI Modid: xfs-linux:slinx:159680a
2003/10/28 23:21:52-06:00 nathans
[XFS] Fix up pointers in diagnostics, print using %p not %x for 64 bit platforms
SGI Modid: xfs-linux:slinx:159652a
2003/10/28 21:01:08-06:00 cattelan
Merge lips.thebarn.com:/export/hose/bkroot/linux-2.4
into lips.thebarn.com:/export/hose/bkroot/linux-2.4+justXFS
2003/10/07 20:34:13-05:00 lord
[XFS] cleanup uio use some more
SGI Modid: xfs-linux:slinx:159633a
2003/10/07 19:24:42-05:00 cattelan
[XFS] switch xfs to use linux imode flags internally
SGI Modid: xfs-linux:slinx:159631a
2003/10/06 16:16:49-05:00 lord
[XFS] Implement deletion of inode clusters in XFS.
SGI Modid: xfs-linux:slinx:159536a
2003/10/06 10:58:41-05:00 cattelan
Merge naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/10/06 10:57:44-05:00 lord
[XFS] fix up error unlock paths in xfs_write
2003/10/06 10:54:18-05:00 lord
[XFS] fix the previous change which compiled by fluke, the conditional
use of the i_alloc_sem was wrong. No actual change in the generated
code for 2.4.22, there will be for older kernels though.
SGI Modid: xfs-linux:slinx:159426a
2003/10/06 10:49:57-05:00 lord
[XFS] small cleanup
SGI Modid: xfs-linux:slinx:159477a
2003/10/06 10:49:07-05:00 cattelan
[XFS] Fix remount,ro path
SGI Modid: xfs-linux:slinx:159444a
2003/10/06 10:47:32-05:00 lord
[XFS] Code cleanup
SGI Modid: xfs-linux:slinx:159439a
2003/10/06 10:45:52-05:00 lord
[XFS] move unwritten extent conversion for O_DIRECT into the write
thread and out of the I/O completion threads. This scales
better.
2003/10/06 10:44:52-05:00 lord
[XFS] Rework how xfs and the linux generic I/O code interoperate
again to deal with deadlock issues between the i_sem and
i_alloc_sem and the xfs IO lock.
SGI Modid: xfs-linux:slinx:159239a
2003/10/06 10:43:32-05:00 lord
[XFS] When calculating the number of pages to probe for an unwritten extent,
use the size of the extent, not the page count of the pagebuf which is
initialized to zero.
2003/09/29 11:02:59-05:00 cattelan
Merge naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4
into naboo.americas.sgi.com:/go/space/BKpulls/linux-2.4+justXFS
2003/09/26 15:03:58-05:00 nathans
[XFS] Clean up inode revalidation code slightly
SGI Modid: xfs-linux:slinx:159031a
2003/09/26 15:03:03-05:00 nathans
[XFS] Fix a broken interaction between a buffered read into an unwritten extent and a direct write
2003/09/24 17:20:02-05:00 roehrich
[XFS] Make dm_send_data_event use vp rather than bhv
SGI Modid: xfs-linux:slinx:158840a
2003/09/24 17:09:17-05:00 lord
[XFS] Close some holes in the metadata flush logic used during unmount,
make sure we have no pending I/O completion calls for metadata,
and that we only keep hold of metadata buffers for I/O completion
if we want to. Still not perfect, but better than it was.
SGI Modid: xfs-linux:slinx:158933a
2003/09/24 17:08:02-05:00 lord
[XFS] remove dead function xfs_trans_iput
SGI Modid: xfs-linux:slinx:158917a
2003/09/23 11:10:33-05:00 lord
[XFS] Switch pagebuf hashing to be based on the block_device address
rather than the dev_t. Should give better distribution.
SGI Modid: xfs-linux:slinx:158800a
2003/09/23 10:51:37-05:00 nathans
[XFS] Rename _inode_init_once to __inode_init_once to follow the kernel naming convention a bit more closely.
2003/09/22 15:27:42-05:00 lord
[XFS] remove an impossible code path from mkdir and link paths,
spotted by Al Viro.
SGI Modid: xfs-linux:slinx:155518a
2003/09/22 15:26:30-05:00 nathans
[XFS] Use xfs_dev_t size rather than dev_t size in xfs_attr_fork initialization
SGI Modid: xfs-linux:slinx:155551a
2003/09/22 15:25:37-05:00 nathans
[XFS] Use the same name for a function here as in the 2.5/2.6 tree
SGI Modid: xfs-linux:slinx:155552a
2003/09/22 15:22:02-05:00 nathans
[XFS] Remove xfs_attr_fetch.c - the one routine was a copy of another, so instead of fixing a bug in two places I merged the two routines.
SGI Modid: xfs-linux:slinx:157533a
2003/09/22 15:19:07-05:00 sandeen
[XFS] Allow full 32 bits in sector number when XFS_BIG_BLKNOS not set
SGI Modid: xfs-linux:slinx:158757a
2003/09/22 15:18:25-05:00 roehrich
[XFS] Change dm_send_destroy_event to use vnode ptrs rather than bhv ptrs
SGI Modid: xfs-linux:slinx:158752a
2003/09/22 15:17:43-05:00 nathans
[XFS] Change writepage code so that we mark a page uptodate if all of its buffers are uptodate, and we are not doing a partial page write
SGI Modid: xfs-linux:slinx:158720a
2003/09/22 15:16:44-05:00 lord
[XFS] Make xfs_ichgtime call mark_inode_dirty_sync instead of mark_inode_dirty
makes the just the inode look dirty, and not the inode and the data.
SGI Modid: xfs-linux:slinx:158670a
2003/09/22 15:16:00-05:00 sandeen
[XFS] Update sysctls - use ints, not ulongs, and show pagebuf
values in jiffies like everybody else
SGI Modid: xfs-linux:slinx:158665a
2003/09/22 15:15:09-05:00 sandeen
[XFS] Re-work pagebuf stats macros to help support per-cpu data
SGI Modid: xfs-linux:slinx:158653a
2003/09/22 15:14:26-05:00 nathans
[XFS] Make debug code _exactly_ how it used to be to save on tree merging.
SGI Modid: xfs-linux:slinx:158641a
2003/09/22 15:13:38-05:00 nathans
[XFS] Allow syncing the types header up more easily with userspace.
SGI Modid: xfs-linux:slinx:158640a
2003/09/22 15:12:52-05:00 nathans
[XFS] Accidentally switched some debug code off, reenable it.
SGI Modid: xfs-linux:slinx:158639a
2003/09/22 15:12:05-05:00 lord
[XFS] fix build for gcc 3.2
SGI Modid: xfs-linux:slinx:158511a
2003/09/22 15:10:27-05:00 nathans
[XFS] Some tweaks to the additional inode flags, suggested by Ethan
SGI Modid: xfs-linux:slinx:158493a
2003/09/22 15:07:05-05:00 nathans
[XFS] Implement several additional inode flags - immutable, append-only, etc; contributed by Ethan Benson.
SGI Modid: xfs-linux:slinx:158362a
2003/09/22 15:06:04-05:00 nathans
[XFS] Separate the big filesystems macro out into separate big inums and blknos macros; fix the check for too-large filesystems in the process.
SGI Modid: xfs-linux:slinx:158361a
2003/09/22 15:05:17-05:00 nathans
[XFS] Undo last mod, checked in against wrong bug number with wrong change message.
SGI Modid: xfs-linux:slinx:158358a
2003/09/22 15:04:17-05:00 nathans
[XFS] Separate the big filesystems macro out into separate big inums and blknos macros. Also fix the check for too-large filesystems in the process.
SGI Modid: xfs-linux:slinx:158357a
2003/09/22 15:02:11-05:00 nathans
[XFS] DMAPI changes required by direct IO/fcntl setfl interaction races
SGI Modid: xfs-linux:slinx:157938a
2003/09/22 15:01:31-05:00 nathans
[XFS] Fix races between O_DIRECT and fcntl with F_SETFL flag on the XFS IO path
SGI Modid: xfs-linux:slinx:157936a
2003/09/22 15:00:30-05:00 nathans
[XFS] Add inode64 mount option; fix case where growfs can push 32 bit inodes into 64 bit space accidentally - both changes originally from IRIX
SGI Modid: xfs-linux:slinx:157935a
2003/09/22 14:59:44-05:00 sandeen
[XFS] remove doubly-included header files
SGI Modid: xfs-linux:slinx:157933a
2003/09/22 14:58:46-05:00 cattelan
[XFS] IRIX sets KM_SLEEP to 0 but the support routines sets KM_SLEEP to 1.
So somebodys shortcut on irix is incorrect on linux and results in the sleep
behaviour not being set.
SGI Modid: xfs-linux:slinx:157773a
2003/09/22 14:58:04-05:00 cattelan
[XFS] Fix from Christoph
gcc 3.3 complains about this and indeed it can only trigger if
someone magically enlarges __uint8_t :)
SGI Modid: xfs-linux:slinx:157731a
2003/09/22 14:57:12-05:00 cattelan
[XFS] Since we now have embeding trees and XFS has to support LBS which
typically 1 version back from the XFS TOT tree add support
for 2.4.22 with and #if KERNEL_VERSION
SGI Modid: xfs-linux:slinx:157579a
2003/09/22 14:56:02-05:00 nathans
[XFS] Automatically set logbsize for larger stripe units
SGI Modid: xfs-linux:slinx:157534a
2003/09/22 14:53:28-05:00 nathans
[XFS] Alternate, cleaner fix for the ENOSPC/ACL lookup problem
SGI Modid: xfs-linux:slinx:157531a
2003/09/22 14:52:27-05:00 roehrich
[XFS] Change dm_send_mount_event to use vnode ptrs rather than bhv ptrs
SGI Modid: xfs-linux:slinx:157485a
2003/09/22 14:51:43-05:00 roehrich
[XFS] Change dm_send_namesp_event to take vnode ptrs rather than bhv ptrs.
SGI Modid: xfs-linux:slinx:157475a
2003/09/22 14:50:08-05:00 lord
[XFS] fix up xfs_lowbit's use of ffs
SGI Modid: xfs-linux:slinx:156655a
2003/09/22 14:49:19-05:00 sandeen
[XFS] Re-work xfs stats macros to support per-cpu data
SGI Modid: xfs-linux:slinx:156453a
2003/09/22 14:48:14-05:00 roehrich
[XFS] fix some ia64 warnings in dmapi_xfs.c
SGI Modid: xfs-linux:slinx:156432a
2003/09/22 14:47:16-05:00 wessmith
[XFS] Work around gcc 2.96 bug in _lsn_cmp.
SGI Modid: xfs-linux:slinx:156280a
2003/09/22 14:46:05-05:00 nathans
[XFS] Fix a case where we could issue an unwritten extent buffer for IO without it being locked - an instant BUG trigger in the block layer
2003/09/22 14:45:09-05:00 nathans
[XFS] Tweak last dabuf fix, suggested by Steve, no longer uses bitfields but uchars instead
SGI Modid: xfs-linux:slinx:156269a
2003/09/22 14:44:04-05:00 tes
[XFS] pv=892598; rv=nathans@sgi.com;
Change xlog_verify_iclog() to use idx as zero based instead
of 1 based index into array.
Nathan tried this change out on some benchmarks and it seems
to help - stop the assert from happening.
Nathan will do the merge of this mod.
SGI Modid: xfs-linux:slinx:156160a
2003/09/22 14:43:10-05:00 nathans
[XFS] Fix a harmless typo - we were using a pagebuf flag not a bmap flag here; fortunately they have the same value (2).
2003/09/22 14:42:17-05:00 cattelan
[XFS] Clean up fsid_t abuses in dmapi
SGI Modid: xfs-linux:slinx:155999a
2003/09/22 14:41:29-05:00 lord
[XFS] do not put 0x in front of a decimal number, its confusing
SGI Modid: xfs-linux:slinx:155961a
2003/09/22 14:40:46-05:00 nathans
[XFS] Use the rounded down size value for all growfs calculations, else the last AG can be updated incorrectly
SGI Modid: xfs-linux:slinx:155936a
2003/09/22 14:40:00-05:00 cattelan
[XFS] Fix one more fsid_t type.
2003/09/22 14:39:05-05:00 nathans
[XFS] Fix a race condition in async pagebuf IO completion, by moving blk queue manipulation down into pagebuf. Fix some busted comments in page_buf.h, use a more descriptive name for __pagebuf_iorequest.
SGI Modid: xfs-linux:slinx:155788a
2003/09/22 14:38:05-05:00 nathans
[XFS] Fix a compiler warning, sync_fs returns a value
2003/09/22 14:37:05-05:00 cattelan
[XFS] Rework pagebuf_delwri_flush to be list safe
SGI Modid: xfs-linux:slinx:155660a
2003/09/22 14:36:09-05:00 cattelan
[XFS] Fix some inconsistent types
SGI Modid: xfs-linux:slinx:155637a
2003/09/22 14:35:09-05:00 nathans
[XFS] Fix up the default ACL inherit case, in the presence of failure during applying the default ACL (eg. from ENOSPC).
SGI Modid: xfs-linux:slinx:155553a
2003/09/22 14:12:14-05:00 cattelan
Merge
2003/08/07 18:10:18-05:00 cattelan
Import changeset
BKrev: 3fd458catoZoCW3mFe00vC17PifSHA
Members:
ChangeSet:1.4315->1.4316
BitKeeper/etc/gone:1.1->1.2
BitKeeper/etc/gone:INITIAL->1.1
fs/xfs/Makefile:1.1->1.2
fs/xfs/Makefile:INITIAL->1.1
fs/xfs/xfs.h:1.1->1.2
fs/xfs/xfs.h:INITIAL->1.1
fs/xfs/xfs_acl.c:1.1->1.2
fs/xfs/xfs_acl.c:INITIAL->1.1
fs/xfs/xfs_acl.h:1.1->1.2
fs/xfs/xfs_acl.h:INITIAL->1.1
fs/xfs/xfs_ag.h:1.1->1.2
fs/xfs/xfs_ag.h:INITIAL->1.1
fs/xfs/xfs_alloc.c:1.1->1.2
fs/xfs/xfs_alloc.c:INITIAL->1.1
fs/xfs/xfs_alloc.h:1.1->1.2
fs/xfs/xfs_alloc.h:INITIAL->1.1
fs/xfs/xfs_alloc_btree.c:1.1->1.2
fs/xfs/xfs_alloc_btree.c:INITIAL->1.1
fs/xfs/xfs_alloc_btree.h:1.1->1.2
fs/xfs/xfs_alloc_btree.h:INITIAL->1.1
fs/xfs/xfs_arch.h:1.1->1.2
fs/xfs/xfs_arch.h:INITIAL->1.1
fs/xfs/xfs_attr.c:1.1->1.2
fs/xfs/xfs_attr.c:INITIAL->1.1
fs/xfs/xfs_attr.h:1.1->1.2
fs/xfs/xfs_attr.h:INITIAL->1.1
fs/xfs/xfs_attr_leaf.c:1.1->1.2
fs/xfs/xfs_attr_leaf.c:INITIAL->1.1
fs/xfs/xfs_attr_leaf.h:1.1->1.2
fs/xfs/xfs_attr_leaf.h:INITIAL->1.1
fs/xfs/xfs_attr_sf.h:1.1->1.2
fs/xfs/xfs_attr_sf.h:INITIAL->1.1
fs/xfs/xfs_bit.c:1.1->1.2
fs/xfs/xfs_bit.c:INITIAL->1.1
fs/xfs/xfs_bit.h:1.1->1.2
fs/xfs/xfs_bit.h:INITIAL->1.1
fs/xfs/xfs_bmap.c:1.1->1.2
fs/xfs/xfs_bmap.c:INITIAL->1.1
fs/xfs/xfs_bmap.h:1.1->1.2
fs/xfs/xfs_bmap.h:INITIAL->1.1
fs/xfs/xfs_bmap_btree.c:1.1->1.2
fs/xfs/xfs_bmap_btree.c:INITIAL->1.1
fs/xfs/xfs_bmap_btree.h:1.1->1.2
fs/xfs/xfs_bmap_btree.h:INITIAL->1.1
fs/xfs/xfs_btree.c:1.1->1.2
fs/xfs/xfs_btree.c:INITIAL->1.1
fs/xfs/xfs_btree.h:1.1->1.2
fs/xfs/xfs_btree.h:INITIAL->1.1
fs/xfs/xfs_buf.h:1.1->1.2
fs/xfs/xfs_buf.h:INITIAL->1.1
fs/xfs/xfs_buf_item.c:1.1->1.2
fs/xfs/xfs_buf_item.c:INITIAL->1.1
fs/xfs/xfs_buf_item.h:1.1->1.2
fs/xfs/xfs_buf_item.h:INITIAL->1.1
fs/xfs/xfs_cap.c:1.1->1.2
fs/xfs/xfs_cap.c:INITIAL->1.1
fs/xfs/xfs_cap.h:1.1->1.2
fs/xfs/xfs_cap.h:INITIAL->1.1
fs/xfs/xfs_clnt.h:1.1->1.2
fs/xfs/xfs_clnt.h:INITIAL->1.1
fs/xfs/xfs_da_btree.c:1.1->1.2
fs/xfs/xfs_da_btree.c:INITIAL->1.1
fs/xfs/xfs_da_btree.h:1.1->1.2
fs/xfs/xfs_da_btree.h:INITIAL->1.1
fs/xfs/xfs_dfrag.c:1.1->1.2
fs/xfs/xfs_dfrag.c:INITIAL->1.1
fs/xfs/xfs_dfrag.h:1.1->1.2
fs/xfs/xfs_dfrag.h:INITIAL->1.1
fs/xfs/xfs_dinode.h:1.1->1.2
fs/xfs/xfs_dinode.h:INITIAL->1.1
fs/xfs/xfs_dir.c:1.1->1.2
fs/xfs/xfs_dir.c:INITIAL->1.1
fs/xfs/xfs_dir.h:1.1->1.2
fs/xfs/xfs_dir.h:INITIAL->1.1
fs/xfs/xfs_dir2.c:1.1->1.2
fs/xfs/xfs_dir2.c:INITIAL->1.1
fs/xfs/xfs_dir2.h:1.1->1.2
fs/xfs/xfs_dir2.h:INITIAL->1.1
fs/xfs/xfs_dir2_block.c:1.1->1.2
fs/xfs/xfs_dir2_block.c:INITIAL->1.1
fs/xfs/xfs_dir2_block.h:1.1->1.2
fs/xfs/xfs_dir2_block.h:INITIAL->1.1
fs/xfs/xfs_dir2_data.c:1.1->1.2
fs/xfs/xfs_dir2_data.c:INITIAL->1.1
fs/xfs/xfs_dir2_data.h:1.1->1.2
fs/xfs/xfs_dir2_data.h:INITIAL->1.1
fs/xfs/xfs_dir2_leaf.c:1.1->1.2
fs/xfs/xfs_dir2_leaf.c:INITIAL->1.1
fs/xfs/xfs_dir2_leaf.h:1.1->1.2
fs/xfs/xfs_dir2_leaf.h:INITIAL->1.1
fs/xfs/xfs_dir2_node.c:1.1->1.2
fs/xfs/xfs_dir2_node.c:INITIAL->1.1
fs/xfs/xfs_dir2_node.h:1.1->1.2
fs/xfs/xfs_dir2_node.h:INITIAL->1.1
fs/xfs/xfs_dir2_sf.c:1.1->1.2
fs/xfs/xfs_dir2_sf.c:INITIAL->1.1
fs/xfs/xfs_dir2_sf.h:1.1->1.2
fs/xfs/xfs_dir2_sf.h:INITIAL->1.1
fs/xfs/xfs_dir2_trace.c:1.1->1.2
fs/xfs/xfs_dir2_trace.c:INITIAL->1.1
fs/xfs/xfs_dir2_trace.h:1.1->1.2
fs/xfs/xfs_dir2_trace.h:INITIAL->1.1
fs/xfs/xfs_dir_leaf.c:1.1->1.2
fs/xfs/xfs_dir_leaf.c:INITIAL->1.1
fs/xfs/xfs_dir_leaf.h:1.1->1.2
fs/xfs/xfs_dir_leaf.h:INITIAL->1.1
fs/xfs/xfs_dir_sf.h:1.1->1.2
fs/xfs/xfs_dir_sf.h:INITIAL->1.1
fs/xfs/xfs_dmapi.h:1.1->1.2
fs/xfs/xfs_dmapi.h:INITIAL->1.1
fs/xfs/xfs_dmops.c:1.1->1.2
fs/xfs/xfs_dmops.c:INITIAL->1.1
fs/xfs/xfs_error.c:1.1->1.2
fs/xfs/xfs_error.c:INITIAL->1.1
fs/xfs/xfs_error.h:1.1->1.2
fs/xfs/xfs_error.h:INITIAL->1.1
fs/xfs/xfs_extfree_item.c:1.1->1.2
fs/xfs/xfs_extfree_item.c:INITIAL->1.1
fs/xfs/xfs_extfree_item.h:1.1->1.2
fs/xfs/xfs_extfree_item.h:INITIAL->1.1
fs/xfs/xfs_fs.h:1.1->1.2
fs/xfs/xfs_fs.h:INITIAL->1.1
fs/xfs/xfs_fsops.c:1.1->1.2
fs/xfs/xfs_fsops.c:INITIAL->1.1
fs/xfs/xfs_fsops.h:1.1->1.2
fs/xfs/xfs_fsops.h:INITIAL->1.1
fs/xfs/xfs_ialloc.c:1.1->1.2
fs/xfs/xfs_ialloc.c:INITIAL->1.1
fs/xfs/xfs_ialloc.h:1.1->1.2
fs/xfs/xfs_ialloc.h:INITIAL->1.1
fs/xfs/xfs_ialloc_btree.c:1.1->1.2
fs/xfs/xfs_ialloc_btree.c:INITIAL->1.1
fs/xfs/xfs_ialloc_btree.h:1.1->1.2
fs/xfs/xfs_ialloc_btree.h:INITIAL->1.1
fs/xfs/xfs_iget.c:1.1->1.2
fs/xfs/xfs_iget.c:INITIAL->1.1
fs/xfs/xfs_imap.h:1.1->1.2
fs/xfs/xfs_imap.h:INITIAL->1.1
fs/xfs/xfs_inode.c:1.1->1.2
fs/xfs/xfs_inode.c:INITIAL->1.1
fs/xfs/xfs_inode.h:1.1->1.2
fs/xfs/xfs_inode.h:INITIAL->1.1
fs/xfs/xfs_inode_item.c:1.1->1.2
fs/xfs/xfs_inode_item.c:INITIAL->1.1
fs/xfs/xfs_inode_item.h:1.1->1.2
fs/xfs/xfs_inode_item.h:INITIAL->1.1
fs/xfs/xfs_inum.h:1.1->1.2
fs/xfs/xfs_inum.h:INITIAL->1.1
fs/xfs/xfs_iocore.c:1.1->1.2
fs/xfs/xfs_iocore.c:INITIAL->1.1
fs/xfs/xfs_iomap.h:1.1->1.2
fs/xfs/xfs_iomap.h:INITIAL->1.1
fs/xfs/xfs_itable.c:1.1->1.2
fs/xfs/xfs_itable.c:INITIAL->1.1
fs/xfs/xfs_itable.h:1.1->1.2
fs/xfs/xfs_itable.h:INITIAL->1.1
fs/xfs/xfs_log.c:1.1->1.2
fs/xfs/xfs_log.c:INITIAL->1.1
fs/xfs/xfs_log.h:1.1->1.2
fs/xfs/xfs_log.h:INITIAL->1.1
fs/xfs/xfs_log_priv.h:1.1->1.2
fs/xfs/xfs_log_priv.h:INITIAL->1.1
fs/xfs/xfs_log_recover.c:1.1->1.2
fs/xfs/xfs_log_recover.c:INITIAL->1.1
fs/xfs/xfs_log_recover.h:1.1->1.2
fs/xfs/xfs_log_recover.h:INITIAL->1.1
fs/xfs/xfs_mac.c:1.1->1.2
fs/xfs/xfs_mac.c:INITIAL->1.1
fs/xfs/xfs_mac.h:1.1->1.2
fs/xfs/xfs_mac.h:INITIAL->1.1
fs/xfs/xfs_macros.c:1.1->1.2
fs/xfs/xfs_macros.c:INITIAL->1.1
fs/xfs/xfs_macros.h:1.1->1.2
fs/xfs/xfs_macros.h:INITIAL->1.1
fs/xfs/xfs_mount.c:1.1->1.2
fs/xfs/xfs_mount.c:INITIAL->1.1
fs/xfs/xfs_mount.h:1.1->1.2
fs/xfs/xfs_mount.h:INITIAL->1.1
fs/xfs/xfs_qmops.c:1.1->1.2
fs/xfs/xfs_qmops.c:INITIAL->1.1
fs/xfs/xfs_quota.h:1.1->1.2
fs/xfs/xfs_quota.h:INITIAL->1.1
fs/xfs/xfs_refcache.c:1.1->1.2
fs/xfs/xfs_refcache.c:INITIAL->1.1
fs/xfs/xfs_refcache.h:1.1->1.2
fs/xfs/xfs_refcache.h:INITIAL->1.1
fs/xfs/xfs_rename.c:1.1->1.2
fs/xfs/xfs_rename.c:INITIAL->1.1
fs/xfs/xfs_rtalloc.c:1.1->1.2
fs/xfs/xfs_rtalloc.c:INITIAL->1.1
fs/xfs/xfs_rtalloc.h:1.1->1.2
fs/xfs/xfs_rtalloc.h:INITIAL->1.1
fs/xfs/xfs_rw.c:1.1->1.2
fs/xfs/xfs_rw.c:INITIAL->1.1
fs/xfs/xfs_rw.h:1.1->1.2
fs/xfs/xfs_rw.h:INITIAL->1.1
fs/xfs/xfs_sb.h:1.1->1.2
fs/xfs/xfs_sb.h:INITIAL->1.1
fs/xfs/xfs_trans.c:1.1->1.2
fs/xfs/xfs_trans.c:INITIAL->1.1
fs/xfs/xfs_trans.h:1.1->1.2
fs/xfs/xfs_trans.h:INITIAL->1.1
fs/xfs/xfs_trans_ail.c:1.1->1.2
fs/xfs/xfs_trans_ail.c:INITIAL->1.1
fs/xfs/xfs_trans_buf.c:1.1->1.2
fs/xfs/xfs_trans_buf.c:INITIAL->1.1
fs/xfs/xfs_trans_extfree.c:1.1->1.2
fs/xfs/xfs_trans_extfree.c:INITIAL->1.1
fs/xfs/xfs_trans_inode.c:1.1->1.2
fs/xfs/xfs_trans_inode.c:INITIAL->1.1
fs/xfs/xfs_trans_item.c:1.1->1.2
fs/xfs/xfs_trans_item.c:INITIAL->1.1
fs/xfs/xfs_trans_priv.h:1.1->1.2
fs/xfs/xfs_trans_priv.h:INITIAL->1.1
fs/xfs/xfs_trans_space.h:1.1->1.2
fs/xfs/xfs_trans_space.h:INITIAL->1.1
fs/xfs/xfs_types.h:1.1->1.2
fs/xfs/xfs_types.h:INITIAL->1.1
fs/xfs/xfs_utils.c:1.1->1.2
fs/xfs/xfs_utils.c:INITIAL->1.1
fs/xfs/xfs_utils.h:1.1->1.2
fs/xfs/xfs_utils.h:INITIAL->1.1
fs/xfs/xfs_vfsops.c:1.1->1.2
fs/xfs/xfs_vfsops.c:INITIAL->1.1
fs/xfs/xfs_vnodeops.c:1.1->1.2
fs/xfs/xfs_vnodeops.c:INITIAL->1.1
fs/xfs/xfsidbg.c:1.1->1.2
fs/xfs/xfsidbg.c:INITIAL->1.1
fs/xfs/linux/Makefile:1.1->1.2
fs/xfs/linux/Makefile:INITIAL->1.1
fs/xfs/linux/xfs_aops.c:1.1->1.2
fs/xfs/linux/xfs_aops.c:INITIAL->1.1
fs/xfs/linux/xfs_behavior.c:1.1->1.2
fs/xfs/linux/xfs_behavior.c:INITIAL->1.1
fs/xfs/linux/xfs_behavior.h:1.1->1.2
fs/xfs/linux/xfs_behavior.h:INITIAL->1.1
fs/xfs/linux/xfs_cred.h:1.1->1.2
fs/xfs/linux/xfs_cred.h:INITIAL->1.1
fs/xfs/linux/xfs_file.c:1.1->1.2
fs/xfs/linux/xfs_file.c:INITIAL->1.1
fs/xfs/linux/xfs_fs_subr.c:1.1->1.2
fs/xfs/linux/xfs_fs_subr.c:INITIAL->1.1
fs/xfs/linux/xfs_fs_subr.h:1.1->1.2
fs/xfs/linux/xfs_fs_subr.h:INITIAL->1.1
fs/xfs/linux/xfs_globals.c:1.1->1.2
fs/xfs/linux/xfs_globals.c:INITIAL->1.1
fs/xfs/linux/xfs_globals.h:1.1->1.2
fs/xfs/linux/xfs_globals.h:INITIAL->1.1
fs/xfs/linux/xfs_ioctl.c:1.1->1.2
fs/xfs/linux/xfs_ioctl.c:INITIAL->1.1
fs/xfs/linux/xfs_iomap.c:1.1->1.2
fs/xfs/linux/xfs_iomap.c:INITIAL->1.1
fs/xfs/linux/xfs_iops.c:1.1->1.2
fs/xfs/linux/xfs_iops.c:INITIAL->1.1
fs/xfs/linux/xfs_iops.h:1.1->1.2
fs/xfs/linux/xfs_iops.h:INITIAL->1.1
fs/xfs/linux/xfs_linux.h:1.1->1.2
fs/xfs/linux/xfs_linux.h:INITIAL->1.1
fs/xfs/linux/xfs_lrw.c:1.1->1.2
fs/xfs/linux/xfs_lrw.c:INITIAL->1.1
fs/xfs/linux/xfs_lrw.h:1.1->1.2
fs/xfs/linux/xfs_lrw.h:INITIAL->1.1
fs/xfs/linux/xfs_stats.c:1.1->1.2
fs/xfs/linux/xfs_stats.c:INITIAL->1.1
fs/xfs/linux/xfs_stats.h:1.1->1.2
fs/xfs/linux/xfs_stats.h:INITIAL->1.1
fs/xfs/linux/xfs_super.c:1.1->1.2
fs/xfs/linux/xfs_super.c:INITIAL->1.1
fs/xfs/linux/xfs_super.h:1.1->1.2
fs/xfs/linux/xfs_super.h:INITIAL->1.1
fs/xfs/linux/xfs_sysctl.c:1.1->1.2
fs/xfs/linux/xfs_sysctl.c:INITIAL->1.1
fs/xfs/linux/xfs_sysctl.h:1.1->1.2
fs/xfs/linux/xfs_sysctl.h:INITIAL->1.1
fs/xfs/linux/xfs_version.h:1.1->1.2
fs/xfs/linux/xfs_version.h:INITIAL->1.1
fs/xfs/linux/xfs_vfs.c:1.1->1.2
fs/xfs/linux/xfs_vfs.c:INITIAL->1.1
fs/xfs/linux/xfs_vfs.h:1.1->1.2
fs/xfs/linux/xfs_vfs.h:INITIAL->1.1
fs/xfs/linux/xfs_vnode.c:1.1->1.2
fs/xfs/linux/xfs_vnode.c:INITIAL->1.1
fs/xfs/linux/xfs_vnode.h:1.1->1.2
fs/xfs/linux/xfs_vnode.h:INITIAL->1.1
fs/xfs/pagebuf/Makefile:1.1->1.2
fs/xfs/pagebuf/Makefile:INITIAL->1.1
fs/xfs/pagebuf/page_buf.c:1.1->1.2
fs/xfs/pagebuf/page_buf.c:INITIAL->1.1
fs/xfs/pagebuf/page_buf.h:1.1->1.2
fs/xfs/pagebuf/page_buf.h:INITIAL->1.1
fs/xfs/quota/Makefile:1.1->1.2
fs/xfs/quota/Makefile:INITIAL->1.1
fs/xfs/quota/xfs_dquot.c:1.1->1.2
fs/xfs/quota/xfs_dquot.c:INITIAL->1.1
fs/xfs/quota/xfs_dquot.h:1.1->1.2
fs/xfs/quota/xfs_dquot.h:INITIAL->1.1
fs/xfs/quota/xfs_dquot_item.c:1.1->1.2
fs/xfs/quota/xfs_dquot_item.c:INITIAL->1.1
fs/xfs/quota/xfs_dquot_item.h:1.1->1.2
fs/xfs/quota/xfs_dquot_item.h:INITIAL->1.1
fs/xfs/quota/xfs_qm.c:1.1->1.2
fs/xfs/quota/xfs_qm.c:INITIAL->1.1
fs/xfs/quota/xfs_qm.h:1.1->1.2
fs/xfs/quota/xfs_qm.h:INITIAL->1.1
fs/xfs/quota/xfs_qm_bhv.c:1.1->1.2
fs/xfs/quota/xfs_qm_bhv.c:INITIAL->1.1
fs/xfs/quota/xfs_qm_stats.c:1.1->1.2
fs/xfs/quota/xfs_qm_stats.c:INITIAL->1.1
fs/xfs/quota/xfs_qm_stats.h:1.1->1.2
fs/xfs/quota/xfs_qm_stats.h:INITIAL->1.1
fs/xfs/quota/xfs_qm_syscalls.c:1.1->1.2
fs/xfs/quota/xfs_qm_syscalls.c:INITIAL->1.1
fs/xfs/quota/xfs_quota_priv.h:1.1->1.2
fs/xfs/quota/xfs_quota_priv.h:INITIAL->1.1
fs/xfs/quota/xfs_trans_dquot.c:1.1->1.2
fs/xfs/quota/xfs_trans_dquot.c:INITIAL->1.1
fs/xfs/support/Makefile:1.1->1.2
fs/xfs/support/Makefile:INITIAL->1.1
fs/xfs/support/debug.c:1.1->1.2
fs/xfs/support/debug.c:INITIAL->1.1
fs/xfs/support/debug.h:1.1->1.2
fs/xfs/support/debug.h:INITIAL->1.1
fs/xfs/support/kmem.c:1.1->1.2
fs/xfs/support/kmem.c:INITIAL->1.1
fs/xfs/support/kmem.h:1.1->1.2
fs/xfs/support/kmem.h:INITIAL->1.1
fs/xfs/support/ktrace.c:1.1->1.2
fs/xfs/support/ktrace.c:INITIAL->1.1
fs/xfs/support/ktrace.h:1.1->1.2
fs/xfs/support/ktrace.h:INITIAL->1.1
fs/xfs/support/move.c:1.1->1.2
fs/xfs/support/move.c:INITIAL->1.1
fs/xfs/support/move.h:1.1->1.2
fs/xfs/support/move.h:INITIAL->1.1
fs/xfs/support/mrlock.c:1.1->1.2
fs/xfs/support/mrlock.c:INITIAL->1.1
fs/xfs/support/mrlock.h:1.1->1.2
fs/xfs/support/mrlock.h:INITIAL->1.1
fs/xfs/support/mutex.h:1.1->1.2
fs/xfs/support/mutex.h:INITIAL->1.1
fs/xfs/support/qsort.c:1.1->1.2
fs/xfs/support/qsort.c:INITIAL->1.1
fs/xfs/support/qsort.h:1.1->1.2
fs/xfs/support/qsort.h:INITIAL->1.1
fs/xfs/support/sema.h:1.1->1.2
fs/xfs/support/sema.h:INITIAL->1.1
fs/xfs/support/spin.h:1.1->1.2
fs/xfs/support/spin.h:INITIAL->1.1
fs/xfs/support/sv.h:1.1->1.2
fs/xfs/support/sv.h:INITIAL->1.1
fs/xfs/support/time.h:1.1->1.2
fs/xfs/support/time.h:INITIAL->1.1
fs/xfs/support/uuid.c:1.1->1.2
fs/xfs/support/uuid.c:INITIAL->1.1
fs/xfs/support/uuid.h:1.1->1.2
fs/xfs/support/uuid.h:INITIAL->1.1
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 18:31 ` Andrea Arcangeli
@ 2003-12-15 18:58 ` Larry McVoy
2003-12-15 19:40 ` Andrea Arcangeli
0 siblings, 1 reply; 35+ messages in thread
From: Larry McVoy @ 2003-12-15 18:58 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Sergey Vlasov, linux-kernel
On Mon, Dec 15, 2003 at 07:31:38PM +0100, Andrea Arcangeli wrote:
> you get the 2.4 branch linear history via bkcvs. Though there you lose
> all the granular xfs development changesets instead, the xfs merge
> becames a huge monolithic patch see below. Either way or another you
> lose information compared to true BK. From my part I'm fine with the
> info provided in bkcvs, I'm only correcting Larry statement about him
> providing lots of way to get at the data in a interoperable protocol,
> he's only providing _partial_ data in a interoperable way. I'm stating
> facts, no whining intendend.
You can get at the full patch level granularity via BK/Web, on bkbits,
complete with checkin comments, diffs, whatever you want. There isn't
any more information to give you that is not internal BK information
which is covered by trade secret. We have every right to not provide
you with information about how BitKeeper works and we've already provided
the data in multiple ways.
- You have an open export of the data into bkcvs, this addressed the "I'm not
using BK so I'm at a disadvantage" problem
- You have patch by patch access to the data at bkbits.net for all
repositories, this addressed the "I want the fine granularity of
individual patches" problem.
- I've offered up the tarball+patch update protocol to address the "I'm not
using BK so I can't easily track the latest version of J Random tree"
problem.
And you still think that your needs aren't being addressed and feel the
need to make the claim that there aren't enough ways to get at the data,
that we are only providing partial data.
Forgive me if I don't agree, I don't think any remotely reasonable person
would agree, and I am confident that there is not the slightest chance
that you can get a court to agree.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 18:58 ` Larry McVoy
@ 2003-12-15 19:40 ` Andrea Arcangeli
2003-12-15 21:44 ` Larry McVoy
0 siblings, 1 reply; 35+ messages in thread
From: Andrea Arcangeli @ 2003-12-15 19:40 UTC (permalink / raw)
To: Larry McVoy, Sergey Vlasov, linux-kernel
On Mon, Dec 15, 2003 at 10:58:39AM -0800, Larry McVoy wrote:
> On Mon, Dec 15, 2003 at 07:31:38PM +0100, Andrea Arcangeli wrote:
> > you get the 2.4 branch linear history via bkcvs. Though there you lose
> > all the granular xfs development changesets instead, the xfs merge
> > becames a huge monolithic patch see below. Either way or another you
> > lose information compared to true BK. From my part I'm fine with the
> > info provided in bkcvs, I'm only correcting Larry statement about him
> > providing lots of way to get at the data in a interoperable protocol,
> > he's only providing _partial_ data in a interoperable way. I'm stating
> > facts, no whining intendend.
>
> You can get at the full patch level granularity via BK/Web, on bkbits,
> complete with checkin comments, diffs, whatever you want. There isn't
> any more information to give you that is not internal BK information
> which is covered by trade secret. We have every right to not provide
> you with information about how BitKeeper works and we've already provided
> the data in multiple ways.
>
> - You have an open export of the data into bkcvs, this addressed the "I'm not
> using BK so I'm at a disadvantage" problem
the open export lacks some granular information this is a fact. that's
fine with me though.
> - You have patch by patch access to the data at bkbits.net for all
> repositories, this addressed the "I want the fine granularity of
> individual patches" problem.
I think it's reasonable to write an automated tool that generates all
the granular info for the big merges by doing a lookup on the web for
every single bkcvs changeset, I did something similar already but I
missed the linearization of bkcvs, not maybe it could have a chance to
work. But the last time I attempted to use the web as a "fetch" tool,
not as a "browsing tool with a browser with an human behind" you said if
we would use it that way you would shut it down, that doesn't match my
definition of interoperability or availability very well.
> - I've offered up the tarball+patch update protocol to address the "I'm
> not
> using BK so I can't easily track the latest version of J Random tree"
> problem.
that's an enterely different issue, don't mix things up. That loses
*tons* of information, much more than bkcvs, I'm not even considering
it. that's only useful to projects where the developers don't even
supply tarballs and patches anymore if I understood correctly. On the
kernel we've the bkcvs that doesn't lose that much of information, so I
don't see any use for this tool on the kernel side.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 19:40 ` Andrea Arcangeli
@ 2003-12-15 21:44 ` Larry McVoy
2003-12-15 22:02 ` Andrea Arcangeli
2003-12-15 22:36 ` Tupshin Harper
0 siblings, 2 replies; 35+ messages in thread
From: Larry McVoy @ 2003-12-15 21:44 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: linux-kernel
My apologies, I should have known better than trying to make you happy.
It's time I learned that some people will never be happy no matter what
you do. Fair enough.
Tupshin asked about clarification about using the BK metadata so he can
go work on whatever SCM it is that he's working on this week. It should
be clear from the license but in case it isn't, yes, it's a violation
to use BK to transfer the information about how BK manages the data
to some other SCM developer, directly or indirectly. You have every
right to extract every patch you want, as patches. The second you start
extracting BK metadata for the benefit of some SCM development effort,
that's a violation of the BKL.
It's your data and that data includes your checkin comments but that is
all. It's our tool and the use of our tool to export information how the
data is managed is a violation of our license. I can't imagine this comes
as any surprise, any vendor who has provided some innovation is going
to protect that innovation. BTW - Tupshin knows this, I made it clear
on the phone when he was asking me for a job, so why he's grinding this
ax I don't know.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 21:44 ` Larry McVoy
@ 2003-12-15 22:02 ` Andrea Arcangeli
2003-12-15 22:14 ` Larry McVoy
2003-12-15 22:36 ` Tupshin Harper
1 sibling, 1 reply; 35+ messages in thread
From: Andrea Arcangeli @ 2003-12-15 22:02 UTC (permalink / raw)
To: Larry McVoy, linux-kernel
On Mon, Dec 15, 2003 at 01:44:52PM -0800, Larry McVoy wrote:
> all. It's our tool and the use of our tool to export information how the
is the web your tool too?
in your previous email you said the information is available via bkbits
web. But in an older email you said if we would use the web to fetch
information you would shut it down (for whatever reason, not relevant
for this email). Please clarify this single point: is the "web" a tool
we can use to fetch information? If not (as you claimed months ago),
then the information exported in the web sure can't be classified as
information to use for interoperability as you stated a few emails ago
today.
I'm fine with the partial info in bkcvs, not sure why you say I'm not
happy or why you think my emotions matters at all with this thread.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 22:02 ` Andrea Arcangeli
@ 2003-12-15 22:14 ` Larry McVoy
2003-12-15 22:44 ` Tupshin Harper
0 siblings, 1 reply; 35+ messages in thread
From: Larry McVoy @ 2003-12-15 22:14 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Larry McVoy, linux-kernel
On Mon, Dec 15, 2003 at 11:02:57PM +0100, Andrea Arcangeli wrote:
> On Mon, Dec 15, 2003 at 01:44:52PM -0800, Larry McVoy wrote:
> > all. It's our tool and the use of our tool to export information how the
>
> is the web your tool too?
The web isn't a tool and it certainly isn't our tool. The web server on
bkbits.net is our tool, that's BitKeeper serving up the web pages directly.
> in your previous email you said the information is available via bkbits
> web. But in an older email you said if we would use the web to fetch
> information you would shut it down (for whatever reason, not relevant
> for this email). Please clarify this single point: is the "web" a tool
> we can use to fetch information?
I said I'd shut it down if you melted down the T1 line. We have dual
T1 lines and rate limited them on both ends so that problem is gone.
You can grab all the patches you want from bkbits.net until you start
using those patches to populate another SCM system because at that point
you are using BK in violation of the BK license.
Tupshin wants both the patches and all the details of how the patches have
been put together. I know why he wants it, it's a ton of useful test data
if what you are doing is building a clone of BitKeeper, and that's exactly
why he can't have all the information he wants. It's disingenuous of him
to pretend it is a freedom of speech issue, but I think it's obvious to
everyone what is going on here. If he was actually a kernel developer
using BK he'd be asking us to reduce the amount of information contained
in BitKeeper so that it ran faster which is what Linus wants us to do.
This is all about someone trying to circumvent our license, not about
some valuable information that BK is losing or hiding.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 22:14 ` Larry McVoy
@ 2003-12-15 22:44 ` Tupshin Harper
2003-12-15 23:13 ` Andrea Arcangeli
0 siblings, 1 reply; 35+ messages in thread
From: Tupshin Harper @ 2003-12-15 22:44 UTC (permalink / raw)
To: Larry McVoy; +Cc: Andrea Arcangeli, linux-kernel
Larry McVoy wrote:
>You can grab all the patches you want from bkbits.net until you start
>using those patches to populate another SCM system because at that point
>you are using BK in violation of the BK license.
>
>
NO!!! In this case, you are not using bk, you are accessing information
that is placed in a public place. If your argument were to hold any
water, then people constrained from using bk due to any clause of the
bkl could not access any information on bkbits.net. The mere act of
pointing their browser there would be a violation. Since these people
are not able to agree to the bkl, they are not constrained by the
restrictions of the bkl. The only effect is that they can *never* use bk.
Either browsing bkbits.net is a use of bk and non-licensed people can't
use it, or it is is not a use of bk and none of the bkl restrictions
apply. Can't have it both ways.
-Tupshin
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 22:44 ` Tupshin Harper
@ 2003-12-15 23:13 ` Andrea Arcangeli
0 siblings, 0 replies; 35+ messages in thread
From: Andrea Arcangeli @ 2003-12-15 23:13 UTC (permalink / raw)
To: Tupshin Harper; +Cc: Larry McVoy, linux-kernel
On Mon, Dec 15, 2003 at 02:44:38PM -0800, Tupshin Harper wrote:
> NO!!! In this case, you are not using bk, you are accessing information
> that is placed in a public place. If your argument were to hold any
that is what I meant with the "web" of course (not the web in the sense
of the world wide web at large), with the "web" I meant the bkbits.net
website of course.
> water, then people constrained from using bk due to any clause of the
> bkl could not access any information on bkbits.net. The mere act of
> pointing their browser there would be a violation. Since these people
correct.
> Either browsing bkbits.net is a use of bk and non-licensed people can't
> use it, or it is is not a use of bk and none of the bkl restrictions
> apply. Can't have it both ways.
agreed.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 21:44 ` Larry McVoy
2003-12-15 22:02 ` Andrea Arcangeli
@ 2003-12-15 22:36 ` Tupshin Harper
2003-12-15 22:46 ` Larry McVoy
1 sibling, 1 reply; 35+ messages in thread
From: Tupshin Harper @ 2003-12-15 22:36 UTC (permalink / raw)
To: Larry McVoy; +Cc: Andrea Arcangeli, linux-kernel
Larry McVoy wrote:
>The second you start
>extracting BK metadata for the benefit of some SCM development effort,
>that's a violation of the BKL.
>
>
Right here, you conflate action and intent. I asked about whether
somebody could legally make the changesets of a bitkeeper archive
publicly available. Will you be issuing a cease and desist order to Rik
van Riel for making changesets available at
ftp://nl.linux.org/pub/linux/bk2patch/patches-v2.5/ ??? I have found
this information to be very interesting. I haven't gone off and
developed an nth generation SCM product, but I have gathered a lot of
interesting quantifiable information about kernel development patterns,
statistics, etc. Who's violating what license, exactly?
>It's your data and that data includes your checkin comments but that is
>all. It's our tool and the use of our tool to export information how the
>data is managed is a violation of our license.
>
Can you point out the relevant portion of the BKL? According to the BKL,
changesets fall into the category of "Metadata". The only restrictions
placed on metadata is that they be transmitted to an open logging
server. The only conceivable restriction I can find is the global
non-compete clause contained in 3-d: "Notwithstanding any other terms in
this License, this License is not available to You if You and/or your
employer develop, produce, sell, and/or resell a product which contains
substantially similar capabil- ities of the BitKeeper Software, or, in
the reason- able opinion of BitMover, competes with the BitKeeper
Software."
Does somebody like Rik magically fall under this clause because he makes
changesets publicly available?
-Tupshin
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 22:36 ` Tupshin Harper
@ 2003-12-15 22:46 ` Larry McVoy
2003-12-15 23:08 ` Tupshin Harper
0 siblings, 1 reply; 35+ messages in thread
From: Larry McVoy @ 2003-12-15 22:46 UTC (permalink / raw)
To: Tupshin Harper; +Cc: Larry McVoy, Andrea Arcangeli, linux-kernel
Sigh. Tupshin, everyone hates these discussions and I'm in agreement with
them. What you want to discuss isn't about kernel development, it's about
building SCM systems. There are better places to do that than here.
If you need clarification on whether you are violating our license, consult
a lawyer.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 22:46 ` Larry McVoy
@ 2003-12-15 23:08 ` Tupshin Harper
2003-12-17 4:47 ` Matthew D. Pitts
0 siblings, 1 reply; 35+ messages in thread
From: Tupshin Harper @ 2003-12-15 23:08 UTC (permalink / raw)
To: Larry McVoy; +Cc: Andrea Arcangeli, linux-kernel
Larry McVoy wrote:
>Sigh. Tupshin, everyone hates these discussions and I'm in agreement with
>them. What you want to discuss isn't about kernel development, it's about
>building SCM systems. There are better places to do that than here.
>
>If you need clarification on whether you are violating our license, consult
>a lawyer.
>
>
I'm not asking for legal advice. I'm asking for bitkeeper's position on
fair usage of data. You made a claim that seems to have zero backing in
the bkl. I think asking for a justification of that claim is quite
reasonable. I know for a fact that I'm not violating your license,
because I'm not using your software and haven't agreed to your license.
The implication you made was that certain other people are violating
your license by exporting changesets publicly. If that is true, then
that is highly relevant to this list. kernel.org, for example would have
to remove changeset information such as
http://www.kernel.org/pub/linux/kernel/v2.6/testing/cset/
-Tupshin
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 23:08 ` Tupshin Harper
@ 2003-12-17 4:47 ` Matthew D. Pitts
0 siblings, 0 replies; 35+ messages in thread
From: Matthew D. Pitts @ 2003-12-17 4:47 UTC (permalink / raw)
To: linux-kernel
> The implication you made was that certain other people
> are violating
> your license by exporting changesets publicly. If that is true, then
> that is highly relevant to this list. kernel.org, for example would
> have to remove changeset information such as
> http://www.kernel.org/pub/linux/kernel/v2.6/testing/cset/
In my opinion, what is here is nothing more than information that most
likely does not contain anything that would violate the BK license. The
check-in comments could easily have been take from the bkbits site
and put into HTML code, and there is a gzipped patch that could simply
be gotten through use of BK. Larry, if I'm wrong about any of this, please
feel free to tell me.
> -Tupshin
Matthew D. Pitts
> 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/
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 6:31 ` Martin J. Bligh
2003-12-15 12:11 ` Sergey Vlasov
@ 2003-12-15 15:42 ` Larry McVoy
2003-12-15 15:55 ` Martin J. Bligh
1 sibling, 1 reply; 35+ messages in thread
From: Larry McVoy @ 2003-12-15 15:42 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Larry McVoy, linux-kernel, bitkeeper-users
On Sun, Dec 14, 2003 at 10:31:04PM -0800, Martin J. Bligh wrote:
> One thing that I've wished for in the past which looks like it *might*
> be trivial to do is to grab a raw version of the patch you already
> put out in HTML format, eg if I surf down changesets and get to a page
> like this:
>
> http://linus.bkbits.net:8080/linux-2.5/patch@1.1522?nav=index.html|ChangeSet@-2w|cset@1.1522
We can do that and we will, it's just not hit the top of the priority list.
Given past discussions on this list I had thought there was a strong need
for a way to trivially track any BK tree without BK, maybe I misunderstood
what was being asked.
There isn't any reason we can't do both.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-15 15:42 ` Larry McVoy
@ 2003-12-15 15:55 ` Martin J. Bligh
0 siblings, 0 replies; 35+ messages in thread
From: Martin J. Bligh @ 2003-12-15 15:55 UTC (permalink / raw)
To: Larry McVoy; +Cc: linux-kernel, bitkeeper-users
--Larry McVoy <lm@bitmover.com> wrote (on Monday, December 15, 2003 07:42:26 -0800):
> On Sun, Dec 14, 2003 at 10:31:04PM -0800, Martin J. Bligh wrote:
>> One thing that I've wished for in the past which looks like it *might*
>> be trivial to do is to grab a raw version of the patch you already
>> put out in HTML format, eg if I surf down changesets and get to a page
>> like this:
>>
>> http://linus.bkbits.net:8080/linux-2.5/patch@1.1522?nav=index.html|ChangeSet@-2w|cset@1.1522
>
> We can do that and we will, it's just not hit the top of the priority list.
> Given past discussions on this list I had thought there was a strong need
> for a way to trivially track any BK tree without BK, maybe I misunderstood
> what was being asked.
I suspect different people have different needs ;-)
> There isn't any reason we can't do both.
Thanks!
M.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-14 17:21 RFC - tarball/patch server in BitKeeper Larry McVoy
` (2 preceding siblings ...)
2003-12-15 6:31 ` Martin J. Bligh
@ 2003-12-15 23:18 ` Chris Frey
2003-12-21 20:02 ` Pavel Machek
4 siblings, 0 replies; 35+ messages in thread
From: Chris Frey @ 2003-12-15 23:18 UTC (permalink / raw)
To: Larry McVoy, linux-kernel, bitkeeper-users
On Sun, Dec 14, 2003 at 09:21:56AM -0800, Larry McVoy wrote:
> /*
> * tarball.c copyright (c) 2003 BitMover, Inc.
> *
> * Licensed under the NWL - No Whining License.
> *
> * You may use this, modify this, redistribute this provided you agree:
> * - not to whine about this product or any other products from BitMover, Inc.
> * - that there is no warranty of any kind.
> * - retain this copyright in full.
> */
If this is a serious license (and I assume it is), it is akin to provisions
in other software licenses that prohibit unfavourable reporting on its
feature set.
- Chris
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: RFC - tarball/patch server in BitKeeper
2003-12-14 17:21 RFC - tarball/patch server in BitKeeper Larry McVoy
` (3 preceding siblings ...)
2003-12-15 23:18 ` Chris Frey
@ 2003-12-21 20:02 ` Pavel Machek
2003-12-21 20:46 ` John Bradford
2003-12-24 1:49 ` Larry McVoy
4 siblings, 2 replies; 35+ messages in thread
From: Pavel Machek @ 2003-12-21 20:02 UTC (permalink / raw)
To: Larry McVoy, linux-kernel, bitkeeper-users
Hi!
> and patches. The idea is to make it possible for all trees hosted by
> bkbits.net provide access to the data with a free client (included
~~~~
> below
> in prototype form).
Unfortunately that is not free client for any reasonable definition of
"free"; which matters, because it means that tarball.c is not getting
into any distribution in any form. Someone will simply have to
reimplement it.
Pavel
> /*
> * tarball.c copyright (c) 2003 BitMover, Inc.
> *
> * Licensed under the NWL - No Whining License.
> *
> * You may use this, modify this, redistribute this provided you agree:
> * - not to whine about this product or any other products from BitMover, Inc.
> * - that there is no warranty of any kind.
> * - retain this copyright in full.
> */
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 35+ messages in thread* Re: RFC - tarball/patch server in BitKeeper
2003-12-21 20:02 ` Pavel Machek
@ 2003-12-21 20:46 ` John Bradford
2003-12-24 1:49 ` Larry McVoy
1 sibling, 0 replies; 35+ messages in thread
From: John Bradford @ 2003-12-21 20:46 UTC (permalink / raw)
To: Pavel Machek, Larry McVoy, linux-kernel
> > and patches. The idea is to make it possible for all trees hosted by
> > bkbits.net provide access to the data with a free client (included
> ~~~~
> > below
> > in prototype form).
>
> Unfortunately that is not free client for any reasonable definition of
> "free"; which matters, because it means that tarball.c is not getting
> into any distribution in any form. Someone will simply have to
> reimplement it.
Larry, could you also please clarify one specific point about the NWL
- whether the phrase 'this product or any other products' includes
future products released by BitMover, Inc. after a third party has
agreed to the license or just products released up until the point
that the third party accepts the license.
I.E. if somebody accepts the NWL now, are they permitted, (in terms of
the NWL), to whine about a, (hypothetical), new product that you
release next year, without violating the license?
John.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: RFC - tarball/patch server in BitKeeper
2003-12-21 20:02 ` Pavel Machek
2003-12-21 20:46 ` John Bradford
@ 2003-12-24 1:49 ` Larry McVoy
1 sibling, 0 replies; 35+ messages in thread
From: Larry McVoy @ 2003-12-24 1:49 UTC (permalink / raw)
To: Pavel Machek; +Cc: Larry McVoy, linux-kernel
Hey, Pavel, do me a favor and take me off the cc list. I've unsubscribed
from the Linux kernel list, this is a good example of why. No sense of
humor on your part, and you are whining about a license on a 200 line
chunk of code. Any decent programmer could have reimplemented it in
less time than it took you to complain.
On Sun, Dec 21, 2003 at 09:02:57PM +0100, Pavel Machek wrote:
> Hi!
>
> > and patches. The idea is to make it possible for all trees hosted by
> > bkbits.net provide access to the data with a free client (included
> ~~~~
> > below
> > in prototype form).
>
> Unfortunately that is not free client for any reasonable definition of
> "free"; which matters, because it means that tarball.c is not getting
> into any distribution in any form. Someone will simply have to
> reimplement it.
> Pavel
>
> > /*
> > * tarball.c copyright (c) 2003 BitMover, Inc.
> > *
> > * Licensed under the NWL - No Whining License.
> > *
> > * You may use this, modify this, redistribute this provided you agree:
> > * - not to whine about this product or any other products from BitMover, Inc.
> > * - that there is no warranty of any kind.
> > * - retain this copyright in full.
> > */
>
> --
> When do you have a heart between your knees?
> [Johanka's followup: and *two* hearts?]
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2003-12-24 1:51 UTC | newest]
Thread overview: 35+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-12-14 17:21 RFC - tarball/patch server in BitKeeper Larry McVoy
2003-12-14 23:05 ` Keith Owens
2003-12-14 23:44 ` Larry McVoy
2003-12-15 0:25 ` Keith Owens
2003-12-15 3:47 ` Larry McVoy
2003-12-14 23:17 ` Tupshin Harper
2003-12-14 23:43 ` Larry McVoy
2003-12-15 0:19 ` Tupshin Harper
2003-12-15 3:46 ` Larry McVoy
2003-12-15 6:07 ` Tupshin Harper
2003-12-15 16:02 ` Larry McVoy
2003-12-15 19:52 ` Tupshin Harper
2003-12-15 6:31 ` Martin J. Bligh
2003-12-15 12:11 ` Sergey Vlasov
2003-12-15 13:27 ` Ben Collins
2003-12-15 16:24 ` Sergey Vlasov
2003-12-15 16:32 ` Larry McVoy
2003-12-15 18:31 ` Andrea Arcangeli
2003-12-15 18:58 ` Larry McVoy
2003-12-15 19:40 ` Andrea Arcangeli
2003-12-15 21:44 ` Larry McVoy
2003-12-15 22:02 ` Andrea Arcangeli
2003-12-15 22:14 ` Larry McVoy
2003-12-15 22:44 ` Tupshin Harper
2003-12-15 23:13 ` Andrea Arcangeli
2003-12-15 22:36 ` Tupshin Harper
2003-12-15 22:46 ` Larry McVoy
2003-12-15 23:08 ` Tupshin Harper
2003-12-17 4:47 ` Matthew D. Pitts
2003-12-15 15:42 ` Larry McVoy
2003-12-15 15:55 ` Martin J. Bligh
2003-12-15 23:18 ` Chris Frey
2003-12-21 20:02 ` Pavel Machek
2003-12-21 20:46 ` John Bradford
2003-12-24 1:49 ` Larry McVoy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox