[bk patch] Make cardbus compile in -pre4

[bk patch] Make cardbus compile in -pre4

[Patrick Mochel]

I broke cardbus compile in -pre4 on accident. Sorry about that...

(I don't have a public repository yet, so there's no place to pull form)

diffstat results: 
 drivers/pcmcia/cardbus.c |    3 +--
 1 files changed, 1 insertion, 2 deletions

ChangeSet
  1.231 02/02/08 18:22:27 mochel@segfault.osdlab.org +1 -0
  Doh! 
  struct device has no ->sysdata
  and ->device should be ->dev
   

  drivers/pcmcia/cardbus.c
    1.7 02/02/08 18:22:27 mochel@segfault.osdlab.org +1 -2
    Doh! 
    struct device has no ->sysdata
    and ->device should be ->dev
     


diff -Nru a/drivers/pcmcia/cardbus.c b/drivers/pcmcia/cardbus.c
--- a/drivers/pcmcia/cardbus.c	Fri Feb  8 18:23:08 2002
+++ b/drivers/pcmcia/cardbus.c	Fri Feb  8 18:23:08 2002
@@ -279,8 +279,7 @@
 		pci_readw(dev, PCI_DEVICE_ID, &dev->device);
 		dev->hdr_type = hdr & 0x7f;
 
-		dev->dev.parent = bus->device;
-		dev->dev.sysdata = bus->sysdata;
+		dev->dev.parent = bus->dev;
 		strcpy(dev->dev.name, dev->name);
 		strcpy(dev->dev.bus_id, dev->slot_name);
 		device_register(&dev->dev);

Re: [bk patch] Make cardbus compile in -pre4

[Andreas Dilger]

On Feb 08, 2002  18:25 -0800, Patrick Mochel wrote:
> (I don't have a public repository yet, so there's no place to pull form)

I don't see why everyone who is using BK is expecting Linus to do a pull.
In the non-BK case, wasn't it always a "push" model, and Linus would not
"pull" from URLs and such?  Why are people not simply doing:

!bk send -r+ (other options) - 

from within their editor (or equivalent) to inline the CSET in the email?
This has the added advantage that other people reading the email can also
import the CSET immediately if they so desire.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [bk patch] Make cardbus compile in -pre4

[Jeff Garzik]

Andreas Dilger wrote:
> 
> On Feb 08, 2002  18:25 -0800, Patrick Mochel wrote:
> > (I don't have a public repository yet, so there's no place to pull form)
> 
> I don't see why everyone who is using BK is expecting Linus to do a pull.
> In the non-BK case, wasn't it always a "push" model, and Linus would not
> "pull" from URLs and such?  Why are people not simply doing:
> 
> !bk send -r+ (other options) -
> 
> from within their editor (or equivalent) to inline the CSET in the email?
> This has the added advantage that other people reading the email can also
> import the CSET immediately if they so desire.

This is a good point...

'bk pull' is probably most useful to high volume submitters, where the
contents of most patches is either obvious and/or uninteresting.  'bk
send -d -r<rev> -' should be fine for importing.

But this is still a trial run of BK, so who knows what will wind up to
be the best policy for casual submitters.

And there's nothing wrong at all with sending GNU patches...

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: [bk patch] Make cardbus compile in -pre4

[Larry McVoy]

On Fri, Feb 08, 2002 at 08:39:31PM -0700, Andreas Dilger wrote:
> On Feb 08, 2002  18:25 -0800, Patrick Mochel wrote:
> > (I don't have a public repository yet, so there's no place to pull form)

Read the second half below to see how to get one.

> I don't see why everyone who is using BK is expecting Linus to do a pull.

For one, he seems to like that model, if the data is in a well known
place, he can pull it when he is ready.  Makes it easy for him to not
worry about whether he has all the stuff Jeff wants to give him, pull
either says there is nothing to do or it doesn't.

The other issue is that if you do the "bk send -r+" thing, that assumes
that the receiver has the parent of the most recent change.  The patch
will not apply otherwise.  This is one difference between BK & diff/patch.
diff/patch will work in more cases, BK is insistent that the receiver has
everything that the sender had except the data sent.  So if you let Linus
pull from a known place then you know he can apply your patch using BK,
if you don't, then he might be able to apply your patch.

On to the "known place" issue.  One problem people have is having a
place to stash this stuff.  Since BK is a replicating system, you can
have the same data in lots of different places, like your laptop, your
home machine, work machine, whatever, but you need a place that other
people can pull from that is always there.  Anyone can install BK, read
the bkd man page and set up such a place.  For those people who either
don't want to do that, or don't have a place where they can run a BKD,
or they don't trust the BKD software to be secure, or whatever, we've set
up bkbits.net, it's somewhat like sourceforge but right now, at least,
mostly intended for the benefit of the kernel team.  We originally set it
up for the PPC team but anyone can stash a copy of their repository there.

To get the model, think of this as a staging area.  You don't work there,
you don't use that system to do your patches or really do very much at
all.  You work where you work right now.  Make your stuff work, test it
out, and when you are ready, push a copy of it up to bkbits.net and send
out mail.  People can go look at the changelogs, see the diffs, pull the
changes using BK, etc.  And Jeff asked for URL format that he can post 
so you can do a

	wget <URL> 

and you have the patch described in his posting.  That should keep the
non-BK users happy, in essense the BK users are adding the data and
BK may be viewed as a patchbot.  For those who don't like the license
or for whatever reason just like plain patches better, they can slurp
down the patches any time they want.

If you want to get a project space up there, send mail to
support@bitmover.com and we'll send you instructions, it's pretty easy
to set up, you log in and pick a name and add your identity.pub and
you're all set.  There is a little admin shell you can use to populate
your repository.  Then you may push your patches there and point Linus
at them and hope he pulls them.  I can see that in short order Linus
is going to be asking for the "show me everything I don't have on one
web page" tool, but that's cool, we've been meaning to build that one
for a while.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [bk patch] Make cardbus compile in -pre4

[Andrew Morton]

Larry McVoy wrote:
> 
> On Fri, Feb 08, 2002 at 08:39:31PM -0700, Andreas Dilger wrote:
> > On Feb 08, 2002  18:25 -0800, Patrick Mochel wrote:
> > > (I don't have a public repository yet, so there's no place to pull form)
> 
> Read the second half below to see how to get one.
> 
> > I don't see why everyone who is using BK is expecting Linus to do a pull.
> 
> For one, he seems to like that model,

Well I don't.  I'd like to see as many kernel changes as possible
sent to this mailing list, as unified diffs, with an explanation.

-

Re: [bk patch] Make cardbus compile in -pre4

[Andreas Dilger]

On Feb 08, 2002  23:02 -0500, Jeff Garzik wrote:
> Andreas Dilger wrote:
> > I don't see why everyone who is using BK is expecting Linus to do a pull.
> > In the non-BK case, wasn't it always a "push" model, and Linus would not
> > "pull" from URLs and such?  Why are people not simply doing:
> > 
> > !bk send -r+ (other options) -
> > 
> > from within their editor (or equivalent) to inline the CSET in the email?
> > This has the added advantage that other people reading the email can also
> > import the CSET immediately if they so desire.
> 
> 'bk pull' is probably most useful to high volume submitters, where the
> contents of most patches is either obvious and/or uninteresting.

The problem is that (AFAIK) bk pull does not let Linus pick-and-choose
which patches he wants to accept as easily as importing them at the time
he reads each email.  It basically assumes that he wants everything that
is in the repository he is pulling from.

> 'bk send -d -r<rev> -' should be fine for importing.

Yes, that would be my thought as well.  Sadly, running the command

bk send -d -r+ -wgzip_uu -

does not work as I would _hope_ it would, namely putting a regular context
diff at the beginning of the email, and gzip_uu for only the CSET.  That
would give us the best of both worlds, namely a diff to look at (which
most people can read easily), and the compressed CSET for people who
have BK.

I suppose it is possible to do exactly what I want by running both:

bk changes -r<rev>			# generates Changelog
bk export -tpatch -h -du -r<rev>	# generates context diff
bk send -wgzip_uu -r<rev> -		# generates gzipped/uuencoded CSET

This has the added benefit that 'bk export' does not contain changes to
the BK files themselves, only the real changes.

I have no idea if this would confuse BK if you tried to recieve from
a file which had both of these in it...

> But this is still a trial run of BK, so who knows what will wind up to
> be the best policy for casual submitters.
> 
> And there's nothing wrong at all with sending GNU patches...

Oh, I agree that for people without BK they can keep sending patches.
I would prefer that people who _do_ have BK to send the CSET along with
the patch to the mailing list so that you don't have to go hunting for a
specific CSET, or if you can't because you are not currently connected.

This might also be possible if BK could export/import a whole changeset
in patch form, plus some magic stuff at the beginning/end (gzip_uu) which
had all of the BK metadata in it, but I don't know if that is possible or
desirable.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [bk patch] Make cardbus compile in -pre4

[Larry McVoy]

On Sat, Feb 09, 2002 at 12:29:20AM -0700, Andreas Dilger wrote:
> Yes, that would be my thought as well.  Sadly, running the command
> 
> bk send -d -r+ -wgzip_uu -
> 
> does not work as I would _hope_ it would, namely putting a regular context
> diff at the beginning of the email, and gzip_uu for only the CSET.  

Whoops, that's a bug.  Type "bk sendbug" and send us a bug report, we'll
fix it.  Sorry about that.

> > But this is still a trial run of BK, so who knows what will wind up to
> > be the best policy for casual submitters.
> > 
> > And there's nothing wrong at all with sending GNU patches...
> 
> Oh, I agree that for people without BK they can keep sending patches.

It occurs to me that there is no reason you can't generate a regular
patch from BK and mail it to the list w/ the changeset comments.  That
keeps all the non-BK users perfectly happy, nothing has changed for
them and they can use BK or not as they see fit.  In addition, you can
send off a BK patch to Linus and/or stuff a patch into a publicly
available BK tree and point him at it.

If you all can reach any sort of concensus on what is a pleasant patch
format for non-BK users, just tell me, and I'll make sure BK can generate
that sort of patch easily.

> This might also be possible if BK could export/import a whole changeset
> in patch form, plus some magic stuff at the beginning/end (gzip_uu) which
> had all of the BK metadata in it, but I don't know if that is possible or
> desirable.

Well, send -d is essentially that - it's two patches, a GNU patch and a
BK patch.  It was a mistake for us to wrap the whole thing, we should
leave the regular diffs alone and just wrap the BK stuff.  We can do
that.  
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [bk patch] Make cardbus compile in -pre4

[Rob Landley]

On Saturday 09 February 2002 12:32 am, Andrew Morton wrote:
> Larry McVoy wrote:
> > For one, he seems to like that model,
>
> Well I don't.  I'd like to see as many kernel changes as possible
> sent to this mailing list, as unified diffs, with an explanation.

I personally hope one of the patchbot projects (patches-only lists, 
filtered/moderated) gets mature enough to use soon.

Optimizing the bandwidth of Linus and optimizing for the rest of the 
developer community are two seperate problems which may require two seperate 
toolchains.  Posting a patch to the list already isn't enough to get it to 
Linus.  Hasn't been for a while...

Rob

Re: [bk patch] Make cardbus compile in -pre4

[Momchil Velikov]

>>>>> "Rob" == Rob Landley <landley@trommello.org> writes:

Rob> Optimizing the bandwidth of Linus and optimizing for the rest of the 
Rob> developer community are two seperate problems which may require two seperate 
Rob> toolchains.  Posting a patch to the list already isn't enough to get it to 
Rob> Linus.  Hasn't been for a while...

Yeah, right, and now people hope that commiting to some obscure
repository will be enough get it to Linus ?

Lemme tell ya, the result is that it won't get not only to Linus, but
to the majority of the community.

Sorry, hoping that some _tool_ will solve the (supposed) problems in
the kernel development is just plain stupid.

Regards,
-velco

PS. Interesting trend to note is the usually the amount of whining is
inversely proportional to one's contribution to the kernel.

Re: [bk patch] Make cardbus compile in -pre4

[Alexander Viro]

On 9 Feb 2002, Momchil Velikov wrote:

> PS. Interesting trend to note is the usually the amount of whining is
> inversely proportional to one's contribution to the kernel.

<pedantic> to (constant + one's contribution to the kernel).  After all,
Rob has only finite bandwidth.  </pedantic>

Re: [bk patch] Make cardbus compile in -pre4

[David Lang]

and if you keep doing this you will also need to cleanup and implement the
'hardlink for identical files' idea that was batted around a year or so
ago, otherwise with all the copies of the linus tree with a few K of
patches from different developers you'll start to notice the storage space
used, even at today's drive prices :-)

David Lang

 On Fri, 8 Feb 2002, Larry McVoy wrote:

> Date: Fri, 8 Feb 2002 21:12:57 -0800
> From: Larry McVoy <lm@bitmover.com>
> To: Patrick Mochel <mochel@osdl.org>, linux-kernel@vger.kernel.org
> Subject: Re: [bk patch] Make cardbus compile in -pre4
>
> On Fri, Feb 08, 2002 at 08:39:31PM -0700, Andreas Dilger wrote:
> > On Feb 08, 2002  18:25 -0800, Patrick Mochel wrote:
> > > (I don't have a public repository yet, so there's no place to pull form)
>
> Read the second half below to see how to get one.
>
> > I don't see why everyone who is using BK is expecting Linus to do a pull.
>
> For one, he seems to like that model, if the data is in a well known
> place, he can pull it when he is ready.  Makes it easy for him to not
> worry about whether he has all the stuff Jeff wants to give him, pull
> either says there is nothing to do or it doesn't.
>
> The other issue is that if you do the "bk send -r+" thing, that assumes
> that the receiver has the parent of the most recent change.  The patch
> will not apply otherwise.  This is one difference between BK & diff/patch.
> diff/patch will work in more cases, BK is insistent that the receiver has
> everything that the sender had except the data sent.  So if you let Linus
> pull from a known place then you know he can apply your patch using BK,
> if you don't, then he might be able to apply your patch.
>
> On to the "known place" issue.  One problem people have is having a
> place to stash this stuff.  Since BK is a replicating system, you can
> have the same data in lots of different places, like your laptop, your
> home machine, work machine, whatever, but you need a place that other
> people can pull from that is always there.  Anyone can install BK, read
> the bkd man page and set up such a place.  For those people who either
> don't want to do that, or don't have a place where they can run a BKD,
> or they don't trust the BKD software to be secure, or whatever, we've set
> up bkbits.net, it's somewhat like sourceforge but right now, at least,
> mostly intended for the benefit of the kernel team.  We originally set it
> up for the PPC team but anyone can stash a copy of their repository there.
>
> To get the model, think of this as a staging area.  You don't work there,
> you don't use that system to do your patches or really do very much at
> all.  You work where you work right now.  Make your stuff work, test it
> out, and when you are ready, push a copy of it up to bkbits.net and send
> out mail.  People can go look at the changelogs, see the diffs, pull the
> changes using BK, etc.  And Jeff asked for URL format that he can post
> so you can do a
>
> 	wget <URL>
>
> and you have the patch described in his posting.  That should keep the
> non-BK users happy, in essense the BK users are adding the data and
> BK may be viewed as a patchbot.  For those who don't like the license
> or for whatever reason just like plain patches better, they can slurp
> down the patches any time they want.
>
> If you want to get a project space up there, send mail to
> support@bitmover.com and we'll send you instructions, it's pretty easy
> to set up, you log in and pick a name and add your identity.pub and
> you're all set.  There is a little admin shell you can use to populate
> your repository.  Then you may push your patches there and point Linus
> at them and hope he pulls them.  I can see that in short order Linus
> is going to be asking for the "show me everything I don't have on one
> web page" tool, but that's cool, we've been meaning to build that one
> for a while.
> --
> ---
> Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [bk patch] Make cardbus compile in -pre4

[Peter Osterlund]

Patrick Mochel <mochel@osdl.org> writes:

> I broke cardbus compile in -pre4 on accident. Sorry about that...

It compiles in -pre5 but doesn't work unless you also apply the patch
below. Without this patch, bus_id will be empty which makes
device_register fail.

--- linux/drivers/pcmcia/cardbus.c.old	Sat Feb  9 12:39:49 2002
+++ linux/drivers/pcmcia/cardbus.c	Sat Feb  9 12:14:36 2002
@@ -279,13 +279,13 @@
 		pci_readw(dev, PCI_DEVICE_ID, &dev->device);
 		dev->hdr_type = hdr & 0x7f;
 
+		pci_setup_device(dev);
+
 		dev->dev.parent = bus->dev;
 		strcpy(dev->dev.name, dev->name);
 		strcpy(dev->dev.bus_id, dev->slot_name);
 		device_register(&dev->dev);
 
-		pci_setup_device(dev);
-
 		/* FIXME: Do we need to enable the expansion ROM? */
 		for (r = 0; r < 7; r++) {
 			struct resource *res = dev->resource + r;

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: [bk patch] Make cardbus compile in -pre4

[Daniel Phillips]

On February 9, 2002 10:57 am, Momchil Velikov wrote:
> PS. Interesting trend to note is the usually the amount of whining is
> inversely proportional to one's contribution to the kernel.

Complaining and whining are not the same thing.  Some major contributors
have complained, that's why Linus takes this seriously.

-- 
Daniel

Re: [bk patch] Make cardbus compile in -pre4

[Larry McVoy]

On Sat, Feb 09, 2002 at 02:14:52AM -0800, David Lang wrote:
> and if you keep doing this you will also need to cleanup and implement the
> 'hardlink for identical files' idea that was batted around a year or so
> ago, otherwise with all the copies of the linus tree with a few K of
> patches from different developers you'll start to notice the storage space
> used, even at today's drive prices :-)

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

Re: [bk patch] Make cardbus compile in -pre4

[Tom Rini]

On Sat, Feb 09, 2002 at 07:54:25AM -0800, Larry McVoy wrote:
> On Sat, Feb 09, 2002 at 02:14:52AM -0800, David Lang wrote:
> > and if you keep doing this you will also need to cleanup and implement the
> > 'hardlink for identical files' idea that was batted around a year or so
> > ago, otherwise with all the copies of the linus tree with a few K of
> > patches from different developers you'll start to notice the storage space
> > used, even at today's drive prices :-)
> 
> bk clone -l

Erm:
$ bk version
BitKeeper/Free version is bk-2.1.4 20020205155016 for x86-glibc22-linux
Built by: lm@redhat71.bitmover.com in /build/bk-2.1.x-lm/src
Built on: Tue Feb  5 08:01:19 PST 2002
$ bk clone -l
usage:  bk clone [-ql] [-E<env>=<val>] [-r<rev>] [-z[<d>]] <from> [<to>]

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [bk patch] Make cardbus compile in -pre4

[Larry McVoy]

> > bk clone -l
> 
> $ bk version
> BitKeeper/Free version is bk-2.1.4 20020205155016 for x86-glibc22-linux
> Built by: lm@redhat71.bitmover.com in /build/bk-2.1.x-lm/src
> Built on: Tue Feb  5 08:01:19 PST 2002
> $ bk clone -l
> usage:  bk clone [-ql] [-E<env>=<val>] [-r<rev>] [-z[<d>]] <from> [<to>]

Tom, I can't believe you are running that ancient version of BK, why it is
already 4 days old!  Try and stay current :-)

There is a 2.1.4b release that has clone -l in it, along with some rollup
fixes/enhancements for Linus.

There is an undocumented version of clone -l in your release which works like

	bk lclone from to

and does the hardlinks.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [bk patch] Make cardbus compile in -pre4

[Rob Landley]

On Saturday 09 February 2002 05:01 am, Alexander Viro wrote:
> On 9 Feb 2002, Momchil Velikov wrote:
> > PS. Interesting trend to note is the usually the amount of whining is
> > inversely proportional to one's contribution to the kernel.
>
> <pedantic> to (constant + one's contribution to the kernel).  After all,
> Rob has only finite bandwidth.  </pedantic>

And here I thought I was still in Al's killfile... :)

Rob

Re: [bk patch] Make cardbus compile in -pre4

[David Lang]

do you have a script that can go back after the fact and see what can be
hardlinked?

I'm thinking specififcly of the type of thing that will be happening to
your server where you have a bunch of people putting in a clone of one
tree who will probably not be doing a clone -l to set it up, but who could
have and you want to clean up after the fact (and perhapse again on a
periodic basis, becouse after all of these trees apply a changeset from
linus they will all have changed (breaking the origional hardlinks) but
will still be duplicates of each other.

David Lang


On Sat, 9 Feb 2002, Larry McVoy wrote:

> Date: Sat, 9 Feb 2002 09:05:27 -0800
> From: Larry McVoy <lm@bitmover.com>
> To: Tom Rini <trini@kernel.crashing.org>
> Cc: David Lang <dlang@diginsite.com>, Larry McVoy <lm@bitmover.com>,
>      Patrick Mochel <mochel@osdl.org>, linux-kernel@vger.kernel.org
> Subject: Re: [bk patch] Make cardbus compile in -pre4
>
> > > bk clone -l
> >
> > $ bk version
> > BitKeeper/Free version is bk-2.1.4 20020205155016 for x86-glibc22-linux
> > Built by: lm@redhat71.bitmover.com in /build/bk-2.1.x-lm/src
> > Built on: Tue Feb  5 08:01:19 PST 2002
> > $ bk clone -l
> > usage:  bk clone [-ql] [-E<env>=<val>] [-r<rev>] [-z[<d>]] <from> [<to>]
>
> Tom, I can't believe you are running that ancient version of BK, why it is
> already 4 days old!  Try and stay current :-)
>
> There is a 2.1.4b release that has clone -l in it, along with some rollup
> fixes/enhancements for Linus.
>
> There is an undocumented version of clone -l in your release which works like
>
> 	bk lclone from to
>
> and does the hardlinks.
> --
> ---
> Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm
>

Re: [bk patch] Make cardbus compile in -pre4

[Larry McVoy]

On Sat, Feb 09, 2002 at 01:01:34PM -0800, David Lang wrote:
> do you have a script that can go back after the fact and see what can be
> hardlinked?
> 
> I'm thinking specififcly of the type of thing that will be happening to
> your server where you have a bunch of people putting in a clone of one
> tree who will probably not be doing a clone -l to set it up, but who could
> have and you want to clean up after the fact (and perhapse again on a
> periodic basis, becouse after all of these trees apply a changeset from
> linus they will all have changed (breaking the origional hardlinks) but
> will still be duplicates of each other.

We don't, but we can, and we should.  "bk relink tree1 tree2" seems like 
the right interface.

Right now we aren't too worried about the disk space, the data is sitting 
on a pair of 40GB drives and we're running the trees in gzip mode, so they
are 75MB each.  But yes, it's a good idea, we should do it, and probably
should figure out some way to make it automatic.  I'll add it to the
(ever growing) list, thanks.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [bk patch] Make cardbus compile in -pre4

[Andreas Dilger]

On Feb 09, 2002  13:41 -0800, Larry McVoy wrote:
> We don't, but we can, and we should.  "bk relink tree1 tree2" seems like 
> the right interface.

Yes, this would be great.  It should probably only do this for files in
SCCS and BitKeeper directories, because vim (for example) will do the
wrong thing with hard-linked files if you edit them.  Maybe there could
be another option which would relink all of the checked-out files as well,
for people who use emacs?

> Right now we aren't too worried about the disk space, the data is sitting 
> on a pair of 40GB drives and we're running the trees in gzip mode, so they
> are 75MB each.  But yes, it's a good idea, we should do it, and probably
> should figure out some way to make it automatic.  I'll add it to the
> (ever growing) list, thanks.

One thing that I've noticed (got my first linux-2.5 clone last night) is
that the kernel build process is somewhat broken by the fact that not
everything that you need to build is checked out of the repository by
make.

It appears to handle .c files ok, but it failed for all of the .h files.
I take it this means that gcc doesn't know anything about SCCS, and it
would also appear that make is not properly checking dependencies for
these files, or it would have checked them out, right?

Also, things like "make menuconfig" and such also fail (because they are
doing stuff within scripts that have no concept of SCCS or BK).  Will
the new kernel build system take any of this into account?

I would prefer if we only checked out as much as we need (instead of
doing something like 'bk -r edit' which will use up a lot of space in
each clone for architectures and drivers which I don't need).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [bk patch] Make cardbus compile in -pre4

[Tom Rini]

On Sat, Feb 09, 2002 at 04:36:03PM -0700, Andreas Dilger wrote:
 
> One thing that I've noticed (got my first linux-2.5 clone last night) is
> that the kernel build process is somewhat broken by the fact that not
> everything that you need to build is checked out of the repository by
> make.
> 
> It appears to handle .c files ok, but it failed for all of the .h files.
> I take it this means that gcc doesn't know anything about SCCS, and it
> would also appear that make is not properly checking dependencies for
> these files, or it would have checked them out, right?

It's a 'feature' of the dependancy setup of the kernel.  bk -r get -q
will checkout all of the files everywhere, and the build _should_ work
(there's been times autogenerated files were in the kernel and thus
broke building from a bk repo).

> Also, things like "make menuconfig" and such also fail (because they are
> doing stuff within scripts that have no concept of SCCS or BK).  Will
> the new kernel build system take any of this into account?

I don't think they do now, but it wouldn't be too hard I'd think.  If of
course the files needed to build/run the tools get checked out :)

> I would prefer if we only checked out as much as we need (instead of
> doing something like 'bk -r edit' which will use up a lot of space in
> each clone for architectures and drivers which I don't need).

Don't -r edit, -r get.  You can go and selectively clean out some dirs,
but in short, no.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [bk patch] Make cardbus compile in -pre4

[Larry McVoy]

On Sat, Feb 09, 2002 at 04:36:03PM -0700, Andreas Dilger wrote:
> On Feb 09, 2002  13:41 -0800, Larry McVoy wrote:
> > We don't, but we can, and we should.  "bk relink tree1 tree2" seems like 
> > the right interface.
> 
> Yes, this would be great.  It should probably only do this for files in
> SCCS and BitKeeper directories, because vim (for example) will do the

Correct.

> One thing that I've noticed (got my first linux-2.5 clone last night) is
> that the kernel build process is somewhat broken by the fact that not
> everything that you need to build is checked out of the repository by
> make.
> 
> It appears to handle .c files ok, but it failed for all of the .h files.

This is because the dependencies are incorrect in the makefiles.  If you
have correct dependencies in the makefiles, make will do the right thing.

One alternative would be to have a scripts/bk-get which takes as an arg
the architecture[s] you want and gets the files that make sense for
that architecture.  That would help somewhat.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: [bk patch] Make cardbus compile in -pre4

[Andreas Dilger]

On Feb 09, 2002  16:45 -0700, Tom Rini wrote:
> On Sat, Feb 09, 2002 at 04:36:03PM -0700, Andreas Dilger wrote:
> > One thing that I've noticed (got my first linux-2.5 clone last night) is
> > that the kernel build process is somewhat broken by the fact that not
> > everything that you need to build is checked out of the repository by
> > make.
> > 
> > It appears to handle .c files ok, but it failed for all of the .h files.
> > I take it this means that gcc doesn't know anything about SCCS, and it
> > would also appear that make is not properly checking dependencies for
> > these files, or it would have checked them out, right?
> 
> It's a 'feature' of the dependancy setup of the kernel.  bk -r get -q
> will checkout all of the files everywhere, and the build _should_ work
> (there's been times autogenerated files were in the kernel and thus
> broke building from a bk repo).

Well, I looked at it some more, and "make dep" was totally broken
until I "bk get" the headers.  All of the .depend files were empty,
probably because "make dep" couldn't find/read any files.  It may
be enough to fix this by having "make dep" do something to "bk get"
each file if it is not there.  It still appears to be a bit of
a problem, because before you do "bk get", "find" does not return any
files for mkdep to look at, a bit of chicken-and-egg problem there.

We could also try to "make" each header file, because make is smart
enough to handle SCCS/BK, CVS, etc so we won't be putting BK-specific
knowledge into the make system (try "make -d include/linux/fs.h").  I
don't know for sure, since I've never worked with the build system much.

> > I would prefer if we only checked out as much as we need (instead of
> > doing something like 'bk -r edit' which will use up a lot of space in
> > each clone for architectures and drivers which I don't need).
> 
> Don't -r edit, -r get.

Well, write bits don't take up any space.  While I can alias vi='bk vim'
to check out a particular file for editing, VIM is not smart enough (or
I don't know how to configure it) to check out files for editing if I
open them from within the editor or use tags to jump to the file.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [bk patch] Make cardbus compile in -pre4

[Jeff Garzik]

Andreas Dilger wrote:
> The problem is that (AFAIK) bk pull does not let Linus pick-and-choose
> which patches he wants to accept as easily as importing them at the time
> he reads each email.  It basically assumes that he wants everything that
> is in the repository he is pulling from.

Yes and no.  'bk pull' does indeed make the presumption that Linus will
like or dislike the entire patchset being pulled.  That's why one wants
to separate different types of changes into different BK trees.  For
example you might have a BK clone with just ext2 fixes, then a BK clone
off of your ext2-fixes tree which contains your ext2 resize work.  Or,
if you wanted those separate and not parent-child, you could clone both
ext2-fixes and ext2-resize trees off of Linus's standard tree.

But I disagree a bit.  Basically, if you organize the trees from which
Linus would do a 'bk pull' then he can easily (a) 'bk unpull' if he
dislikes everything, and (b) easily inspect each changeset.

I personally plan on sending Linus GNU patches simply for his review, as
I did with the recent swap_device cleanup patch, as well as giving him a
location for doing the 'bk pull'.  In that specific case, there was a
tree http://gkernel.bkbits.net/vm-2.5 which contained nothing but that
one change.

Used in this sense, 'bk pull' is really the primary merging tool, and
e-mail is simply a reminder to Linus that he should do a pull.

	Jeff



-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

Re: [bk patch] Make cardbus compile in -pre4

[Linus Torvalds]

In article <20020209002920.Z15496@lynx.turbolabs.com>,
Andreas Dilger  <adilger@turbolabs.com> wrote:
>
>The problem is that (AFAIK) bk pull does not let Linus pick-and-choose
>which patches he wants to accept as easily as importing them at the time
>he reads each email.  It basically assumes that he wants everything that
>is in the repository he is pulling from.

Yes and no.

I hope that the developers that I work enough with for it to matter tend
to be fairly good at keeping things separate (ie separate BK trees for
different development efforts etc), in which case it's not a big issue.

And yes, from at least one developer I have already done a partial pull,
ie taken only partial changes. In that case the changes I disagreed with
were at the end, so it was easy enough to just do a "bk pull" into
another tree, do a "bk undo", and only merge after that.

But I agree - if I end up having to do that more than occasionally, I'm
going to ask that developer to stop using bk at least as far as I'm
concerned (ie he can use bk for himself, but I wouldn't accept bk
patches from developers who cannot keep their stuff cleanly separated).

		Linus

Re: [bk patch] Make cardbus compile in -pre4

[Linus Torvalds]

In article <E16ZZ7M-0007Y7-00@starship.berlin>,
Daniel Phillips  <phillips@bonn-fries.net> wrote:
>
>Complaining and whining are not the same thing.  Some major contributors
>have complained, that's why Linus takes this seriously.

Well, in all honesty, it's not so much that I take it seriously - it's
not as if the complaints are in any way new (or even more serious than
before - I think we had a much more serious spat a few years ago).  The
fact is, people will _always_ complain about the way things are done.

[ This very _same_ "how to maintain" flameware is not only a regular
  topic on linux-kernel, it's a regular topic on the BSD lists, on the
  gcc lists, and probably on every single bigger software project,
  whether open source or not. Why do you think there are so many
  different source control packages? ;]

But I _have_ promised Larry for the last two years or so to give BK a
chance (the last time I promised him I'd start using it as of 2.5.0),
and the discussion to a large degree just made me feel I had a good
reason to take a week off and try it out. 

I doubt bk per se will really change any of the real issues.  It will
almost certainly make it somewhat easier to merge patches from some
people, but I also suspect that those are largely the same people that I
already was pretty good at merging patches from before. 

The fundamental issue that I think I (or any human, for that matter)
work best with just a few (on the order of ten) closer contacts, and
that I want people to "network" more is pretty independent of BK or not.

However, in the long run what BK may do is to make it easier to migrate
to a "group model", where the traditional "linus tree" doesn't even
exist any more. I'm not ready to do that yet, but clearly it has to
happen at _some_ point. Nobody lives forever.

And I do like BK so far.

			Linus

Re: [bk patch] Make cardbus compile in -pre4

[Linus Torvalds]

In article <20020209155258.E18734@work.bitmover.com>,
Larry McVoy  <lm@bitmover.com> wrote:
>
>This is because the dependencies are incorrect in the makefiles.  If you
>have correct dependencies in the makefiles, make will do the right thing.

Modulo bugs.

For some reason, on my work machine, "make" will not correctly check out
files that are "include"d from the makefile.

On my home machine, it will.

The really interesting thing is, they're both make 3.79.1.

Besides, I'd at least personally rather do "bk -r get -q" than have to
watch those SCCS files and BitKeeper files. That way the filename
completion works inside the shell too..

			Linus

Re: [bk patch] Make cardbus compile in -pre4

[William Stearns]

Good day, Larry,

On Sat, 9 Feb 2002, Larry McVoy wrote:

> On Sat, Feb 09, 2002 at 01:01:34PM -0800, David Lang wrote:
> > do you have a script that can go back after the fact and see what can be
> > hardlinked?
> > 
> > I'm thinking specififcly of the type of thing that will be happening to
> > your server where you have a bunch of people putting in a clone of one
> > tree who will probably not be doing a clone -l to set it up, but who could
> > have and you want to clean up after the fact (and perhapse again on a
> > periodic basis, becouse after all of these trees apply a changeset from
> > linus they will all have changed (breaking the origional hardlinks) but
> > will still be duplicates of each other.
> 
> We don't, but we can, and we should.  "bk relink tree1 tree2" seems like 
> the right interface.
> 
> Right now we aren't too worried about the disk space, the data is sitting 
> on a pair of 40GB drives and we're running the trees in gzip mode, so they
> are 75MB each.  But yes, it's a good idea, we should do it, and probably
> should figure out some way to make it automatic.  I'll add it to the
> (ever growing) list, thanks.

	Larry, I'll save you the time.
	"freedups -a -d /some/dir [/other/dirs]" will look for identical
files (the -d requires dates to be equal as well as the content) and
hardlink them.  It's not terribly efficient, but works marvelously well.  
Run it from cron once a week or so, perhaps?
	http://www.stearns.org/freedups/
	Cheers,
	- Bill

---------------------------------------------------------------------------
        "Patience is a minor form of despair, disguised as virtue."
        -- Ambrose Bierce, on qualifiers
--------------------------------------------------------------------------
William Stearns (wstearns@pobox.com).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:                http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------

Re: [bk patch] Make cardbus compile in -pre4

[Andreas Dilger]

Linus Torvalds <torvalds@transmeta.com> writes:
> from at least one developer I have already done a partial pull,
> ie taken only partial changes. In that case the changes I disagreed with
> were at the end, so it was easy enough to just do a "bk pull" into
> another tree, do a "bk undo", and only merge after that.
> 
> But I agree - if I end up having to do that more than occasionally, I'm
> going to ask that developer to stop using bk at least as far as I'm
> concerned (ie he can use bk for himself, but I wouldn't accept bk
> patches from developers who cannot keep their stuff cleanly separated).

What about BK CSET (or regular patch) submissions from non-core
developers?  Would you accept CSETs via email if they are preceeded
by a unified diff and explanation?  This would make it much easier
for any non-core developer to avoid having to re-sync their changes
with you if/when you accept that change into your tree.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [bk patch] Make cardbus compile in -pre4

[Tom Rini]

On Sat, Feb 09, 2002 at 03:52:58PM -0800, Larry McVoy wrote:
> On Sat, Feb 09, 2002 at 04:36:03PM -0700, Andreas Dilger wrote:
> > On Feb 09, 2002  13:41 -0800, Larry McVoy wrote:
> > > We don't, but we can, and we should.  "bk relink tree1 tree2" seems like 
> > > the right interface.
> > 
> > Yes, this would be great.  It should probably only do this for files in
> > SCCS and BitKeeper directories, because vim (for example) will do the
> 
> Correct.
> 
> > One thing that I've noticed (got my first linux-2.5 clone last night) is
> > that the kernel build process is somewhat broken by the fact that not
> > everything that you need to build is checked out of the repository by
> > make.
> > 
> > It appears to handle .c files ok, but it failed for all of the .h files.
> 
> This is because the dependencies are incorrect in the makefiles.  If you
> have correct dependencies in the makefiles, make will do the right thing.

Or more specifically, the 'dependancy' stage of the kernel knows
_nothing_ about SCCS.  It _might_ not be that hard to hack up the
scripts/mkdep.c program to check if an #include'd file exists (and if it
doesn't, if (any search patch)/SCCS exists, and if so, get it.

> One alternative would be to have a scripts/bk-get which takes as an arg
> the architecture[s] you want and gets the files that make sense for
> that architecture.  That would help somewhat.

If it's just a flat list of files, it'd be rather hellish to maintain
I'd think.  It _might_ not be too horrible to try and glean files from
CONFIG options (but isn't part of the point of the kernel's current dep
system to not depend on CONFIG_xxx options?) and assume all of include/
is needed.

Or kbuild-2.5 might just work since it does deps in a more 'correct'
manner.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [bk patch] Make cardbus compile in -pre4

[Chris Adams]

Once upon a time, Linus Torvalds <torvalds@transmeta.com> said:
>The fundamental issue that I think I (or any human, for that matter)
>work best with just a few (on the order of ten) closer contacts, and
>that I want people to "network" more is pretty independent of BK or not.

What we need is an "Oracle of Linus" like the "Oracle of Bacon" (aka the
"Kevin Bacon" game).  Alan Cox (along with a few others) has a Linus
number of 1 for example.  Now the tree just need to be defined better,
so developers can know their Linus number and know the best path for
them to submit patches.

Just a suggestion from a humble user (with a Bacon number of 1 :-) ).
-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: [bk patch] Make cardbus compile in -pre4

[Linus Torvalds]

On Sun, 10 Feb 2002, Andreas Dilger wrote:
>
> What about BK CSET (or regular patch) submissions from non-core
> developers?  Would you accept CSETs via email if they are preceeded
> by a unified diff and explanation?

What's the difference here with "bk send"?

I have worked with a few BK patches in email, and I have to say that I
pretty much detest them. The less I have to work with them, the better,
although that may just because I don't yet have the same kind of
infrastructure for them as I have for regulat patches.

Making the infrastructure is not that hard, so if people start sending me
bk patches by email, I can improve it, and I'll probably not dislike bk
send as much as I do now.

(But _please_ do a "bk send" to a file, and edit the file before you send
it, instead of sending directly with that "Bitkeeper patch" subject line.
It looks like "bk send" was really designed for automatic merges, not for
humans)

		Linus

Re: [bk patch] Make cardbus compile in -pre4

[Padraig Brady]

William Stearns wrote:
> Good day, Larry,
> 
> On Sat, 9 Feb 2002, Larry McVoy wrote:
> 
> 
>>On Sat, Feb 09, 2002 at 01:01:34PM -0800, David Lang wrote:
>>
>>>do you have a script that can go back after the fact and see what can be
>>>hardlinked?
>>>
>>>I'm thinking specififcly of the type of thing that will be happening to
>>>your server where you have a bunch of people putting in a clone of one
>>>tree who will probably not be doing a clone -l to set it up, but who could
>>>have and you want to clean up after the fact (and perhapse again on a
>>>periodic basis, becouse after all of these trees apply a changeset from
>>>linus they will all have changed (breaking the origional hardlinks) but
>>>will still be duplicates of each other.
>>>
>>We don't, but we can, and we should.  "bk relink tree1 tree2" seems like 
>>the right interface.
>>
>>Right now we aren't too worried about the disk space, the data is sitting 
>>on a pair of 40GB drives and we're running the trees in gzip mode, so they
>>are 75MB each.  But yes, it's a good idea, we should do it, and probably
>>should figure out some way to make it automatic.  I'll add it to the
>>(ever growing) list, thanks.
>>
> 
> 	Larry, I'll save you the time.
> 	"freedups -a -d /some/dir [/other/dirs]" will look for identical
> files (the -d requires dates to be equal as well as the content) and
> hardlink them.  It's not terribly efficient, but works marvelously well.  
> Run it from cron once a week or so, perhaps?
> 	http://www.stearns.org/freedups/
> 	Cheers,
> 	- Bill


Not terribly efficient? That's a bit of an understatement :-)
The findup component of fslint is MUCH quicker, and it's
also written in bash. A quick test against two 2.4.17 trees gives:

1m36s for  ./findup /usr/src/linux[12] | ./fstool/mergeDup
18m17s for ./freedups -a /usr/src/linux[12]

Note mergeDup was a quick hack and took 1m30s of findup's time!
I'm going to rewrite it in python ASAP to help with this.

You can download the current version of fslint from
http://developers.antefacto.net/~padraig/fslint.tar.gz

Padraig.

Re: [bk patch] Make cardbus compile in -pre4

[Andreas Dilger]

On Feb 10, 2002  12:57 -0800, Linus Torvalds wrote:
> On Sun, 10 Feb 2002, Andreas Dilger wrote:
> > What about BK CSET (or regular patch) submissions from non-core
> > developers?  Would you accept CSETs via email if they are preceeded
> > by a unified diff and explanation?
> 
> I have worked with a few BK patches in email, and I have to say that I
> pretty much detest them. The less I have to work with them, the better,
> although that may just because I don't yet have the same kind of
> infrastructure for them as I have for regulat patches.
>
> (But _please_ do a "bk send" to a file, and edit the file before you send
> it, instead of sending directly with that "Bitkeeper patch" subject line.
> It looks like "bk send" was really designed for automatic merges, not for
> humans)

Yes, the first time I used "bk send" to send something directly to Ted it
happened that I was offline so I looked into my mail spool at the emails
and also hated it.  What I was proposing instead of just "bk send" is to
prepend the changelog entry, a real unified diff, and gzip_uu CSET at the
end.  Larry has agreed that "bk send -d -wgzip_uu" wrapping the diff part
of the patch is a bug to be fixed.

So, instead of the current layout of "'This is a BitKeeper patch' comment +
commented-out diff + BK stuff", I would send "CSET ChangeLog + unified diff +
gzip_uu wrapped BK stuff".  This would be the output of (probably in a script):

bk changes -r<rev>
bk export -tpatch -h -du -r<rev>
bk send -wgzip_uu -r<rev> -

For example, your recent 2.5.4 release would look like the below, and I
_think_ you could just accept this with "bk receive -a [repository path]",
but I'm not sure how good the BK heuristics are for finding a CSET at the
end of a long patch.  I'm only skeptical because the current "bk send"
output comments out the diff part of the output.

ChangeSet@1.262, 2002-02-10 19:24:03-08:00, torvalds@home.transmeta.com
  update version
  TAG: v2.5.4

diff -Nru a/Makefile b/Makefile
--- a/Makefile	Mon Feb 11 10:44:32 2002
+++ b/Makefile	Mon Feb 11 10:44:32 2002
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 5
 SUBLEVEL = 4
-EXTRAVERSION =-pre6
+EXTRAVERSION =
 
 KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
 
This BitKeeper patch contains the following changesets:
1.262
## Wrapped with gzip_uu ##


begin 664 bkpatch3560
M'XL(`!\#:#P``[V4T6[;(!2&K\-3(/5RLG,.!H(M>5K71ENU=8V<==HMLFEL
MU;$K0[)6\L./6%U255.R1-LP<,'!1X?OY^>,WEK3)2-=5/7"=.2,?FRM2T;U
M4_,8/B^&5>-\(&M;'QBO;#>V73ZNJV;U&+!0$!^;:9>7=&TZFXPPC+8K[NG!
M)*-L^N'V\WE&2)K2BU(W"S,WCJ8I<6VWUG5AWVE7UFT3NDXW=FF<#O-VV6^W
M]@R`^4_@)`(A>Y3`)WV.!:+F:`I@7$F^RU:V2W,@%R(@CQGO47$AR"7%D$E&
M@8U]1Z`8)XPG$`6@$@"Z)S5]@S0`\I[^W<-<D)RN'@KMS("U:AORB?IBN2*S
M'402'-D(`0WD[8%BK_6]N:MJ\[+6.%(]@)K(OI"ZB'/4JA"QT&(?G->9//:(
M<8AZ%))+<JQDS_\.%*Y_+QF*/Y$,_H5D+W69T[6W1LB)I0L_:C^./2LJ$)ZX
M;R>HO+':+_:'G7:4WGM%>ZVWG[B*X@VR"1MLAE*=;#/\3S8;+N<-#;H?0_=`
M9UN:)XAQR2F2J\TT_?XU._\VS>97-U]HNGLY\]+D]W:U3/%.<B5B)#\!WOU:
%+9D%````
`
end



Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [bk patch] Make cardbus compile in -pre4

[Padraig Brady]

Padraig Brady wrote:
> William Stearns wrote:
> 
>> Good day, Larry,
>>
>> On Sat, 9 Feb 2002, Larry McVoy wrote:
>>
>>
>>> On Sat, Feb 09, 2002 at 01:01:34PM -0800, David Lang wrote:
>>>
>>>> do you have a script that can go back after the fact and see what 
>>>> can be
>>>> hardlinked?
>>>>
>>>> I'm thinking specififcly of the type of thing that will be happening to
>>>> your server where you have a bunch of people putting in a clone of one
>>>> tree who will probably not be doing a clone -l to set it up, but who 
>>>> could
>>>> have and you want to clean up after the fact (and perhapse again on a
>>>> periodic basis, becouse after all of these trees apply a changeset from
>>>> linus they will all have changed (breaking the origional hardlinks) but
>>>> will still be duplicates of each other.
>>>>
>>> We don't, but we can, and we should.  "bk relink tree1 tree2" seems 
>>> like the right interface.
>>>
>>> Right now we aren't too worried about the disk space, the data is 
>>> sitting on a pair of 40GB drives and we're running the trees in gzip 
>>> mode, so they
>>> are 75MB each.  But yes, it's a good idea, we should do it, and probably
>>> should figure out some way to make it automatic.  I'll add it to the
>>> (ever growing) list, thanks.
>>>
>>
>>     Larry, I'll save you the time.
>>     "freedups -a -d /some/dir [/other/dirs]" will look for identical
>> files (the -d requires dates to be equal as well as the content) and
>> hardlink them.  It's not terribly efficient, but works marvelously 
>> well.  Run it from cron once a week or so, perhaps?
>>     http://www.stearns.org/freedups/
>>     Cheers,
>>     - Bill
> 
> 
> 
> Not terribly efficient? That's a bit of an understatement :-)
> The findup component of fslint is MUCH quicker, and it's
> also written in bash. A quick test against two 2.4.17 trees gives:
> 
> 1m36s for  ./findup /usr/src/linux[12] | ./fstool/mergeDup
> 18m17s for ./freedups -a /usr/src/linux[12]
> 
> Note mergeDup was a quick hack and took 1m30s of findup's time!
> I'm going to rewrite it in python ASAP to help with this.
> 
> You can download the current version of fslint from
> http://developers.antefacto.net/~padraig/fslint.tar.gz

OK I've updated fslint which can be downloaded @
http://www.iol.ie/~padraiga/fslint/fslint-1.11.tar.gz
To merge 2 linux trees you do: ./findup -m /usr/src/linux[12]
This will take about 37 seconds (note freedups takes 15
minutes to do the same). Note be careful that your editor
handles hardlinked files as you expect.

Padraig.