2.5 development

2.5 development

[Paul Mackerras]

Now that Linus has started using BK for 2.5 development, I have set up
a new linuxppc-2.5 tree on ppc.bkbits.net.  Its parent is Linus' tree,
which means that we can pull in Linus' changes using BK, instead of
having to apply patches.  The linux_2_5 and linuxppc_2_5 trees are
dead, and I will remove them once we are sure we have all the changes
from linuxppc_2_5 committed to the linuxppc-2.5 tree.

The linuxppc-2.5 tree is intended to be a working tree for us in the
same way that the linuxppc_2_4_devel tree was.  I have checked in
most of the changes from linuxppc_2_4_devel into linuxppc-2.5.

The current limitations of BK mean that we will not be able to take
changesets directly from the linuxppc-2.5 tree and send them to
Linus.  I would suggest that if any of you are working on stuff which
can be isolated as a discrete unit, you can set up a clone of
linux-2.5 where you check in all of the changes for that stuff.  Then
pull from there into your linuxppc-2.5 clone to compile and test, and
push to the linuxppc-2.5 tree on ppc.bkbits.net when you are ready for
the rest of us to look at it.  When it is time for those changes to go
to Linus, we can get Linus to pull from your repository which has just
those changes (or I can pull and get Linus to pull from my tree).

I have also created for-linus-ppc and for-linus-ppcdrivers trees which
I will use to send stuff to Linus, so I don't want anyone except
myself pushing to those trees.  There is also a for-linus-ppc64 tree
which Anton Blanchard will be using to send ppc64 stuff to Linus, so
please don't push to that one either.

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.5 development

[Tom Rini]

On Fri, Feb 15, 2002 at 11:11:57PM +1100, Paul Mackerras wrote:
>
> Now that Linus has started using BK for 2.5 development, I have set up
> a new linuxppc-2.5 tree on ppc.bkbits.net.  Its parent is Linus' tree,
> which means that we can pull in Linus' changes using BK, instead of
> having to apply patches.  The linux_2_5 and linuxppc_2_5 trees are
> dead, and I will remove them once we are sure we have all the changes
> from linuxppc_2_5 committed to the linuxppc-2.5 tree.
>
> The linuxppc-2.5 tree is intended to be a working tree for us in the
> same way that the linuxppc_2_4_devel tree was.  I have checked in
> most of the changes from linuxppc_2_4_devel into linuxppc-2.5.
>
> The current limitations of BK mean that we will not be able to take
> changesets directly from the linuxppc-2.5 tree and send them to
> Linus.  I would suggest that if any of you are working on stuff which
> can be isolated as a discrete unit, you can set up a clone of
> linux-2.5 where you check in all of the changes for that stuff.  Then
> pull from there into your linuxppc-2.5 clone to compile and test, and
> push to the linuxppc-2.5 tree on ppc.bkbits.net when you are ready for
> the rest of us to look at it.  When it is time for those changes to go
> to Linus, we can get Linus to pull from your repository which has just
> those changes (or I can pull and get Linus to pull from my tree).
>
> I have also created for-linus-ppc and for-linus-ppcdrivers trees which
> I will use to send stuff to Linus, so I don't want anyone except
> myself pushing to those trees.  There is also a for-linus-ppc64 tree
> which Anton Blanchard will be using to send ppc64 stuff to Linus, so
> please don't push to that one either.

One other thing, everyone else using the linus tree (and it's
derivations) is using BK 2.1.x, so if you're going to work in these
trees you should probably upgrade too.

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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.5 development

[Larry McVoy]

On Fri, Feb 15, 2002 at 11:11:57PM +1100, Paul Mackerras wrote:
> The current limitations of BK mean that we will not be able to take
> changesets directly from the linuxppc-2.5 tree and send them to
> Linus.

You can export changes as a patch and import them.  Notice that the new
"bk comments" command will let you change the comments after you do the
import.  To get a changeset's comments in a form that bk comments will
like, try this (requires bk 2.1.4 or later):

bk changes -r+ -vnd'### Change the comments to :GFILE: below\n:C:'

That will do it for the most recent changeset, s/+/rev/ that you used
with the export/import.
--
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.5 development

[Jeff Garzik]

Larry McVoy wrote:
>
> On Fri, Feb 15, 2002 at 11:11:57PM +1100, Paul Mackerras wrote:
> > The current limitations of BK mean that we will not be able to take
> > changesets directly from the linuxppc-2.5 tree and send them to
> > Linus.
>
> You can export changes as a patch and import them.  Notice that the new
> "bk comments" command will let you change the comments after you do the
> import.  To get a changeset's comments in a form that bk comments will
> like, try this (requires bk 2.1.4 or later):

FWIW, I prefer to export as a patch, and then 'bk citool' to check in.
If you are going to edit the comments anyway, then re-importing a patch
is best done IMHO with

	patch -sp1 -g1 < ~/tmp/patch
	bk citool

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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.5 development

[Larry McVoy]

> FWIW, I prefer to export as a patch, and then 'bk citool' to check in.

Groovy.  I love it when people use citool, we get better comments.

> If you are going to edit the comments anyway, then re-importing a patch
> is best done IMHO with
>
> 	patch -sp1 -g1 < ~/tmp/patch

The only problem with this is that it doesn't catch renames, so you'll be
adding and deleting files instead of renaming them.  Buried in the import
-tpatch code, you'll find (it's a shell script):

bk patch -g1 -f -p1 -ZsE \
    -z '=-PaTcH_BaCkUp!' --forcetime --lognames > ${TMP}plog$$ 2>&1

and then

grep '^Creating file ' ${TMP}plog$$ | sed 's/Creating file //' > ${TMP}creates$$
grep '^Removing file ' ${TMP}plog$$ | sed 's/Removing file //' > ${TMP}deletes$$
if [ -s ${TMP}deletes$$ -a -s ${TMP}creates$$ ]
then    (
	cat ${TMP}deletes$$
	echo ""
	cat ${TMP}creates$$
	) | bk renametool $Q
fi

which you really want to do, the repository will bloat up with duplicate files
if you don't.

Jeff, aside from the fact it's some unknown black box, what don't you like
about "import -tpatch"?  Is there something we could fix?
--
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.5 development

[Larry McVoy]

To export comments, you need this command (we're add it to the docs): I got it
wrong the first time:

bk changes -r+ -vnd'### Comments for :GFILE:\n$each(:C:){(:C:)\n}'

Yup, those dspecs (printf like things) are pretty weird, but well worth
understanding.  You can do some amazing things with them.  BK/Web is
essentially a pile of big dspecs handed to bk prs.

A very useful thing is this:

bk set -d -rbk-2.1.3 -r+ | bk changes -

which says "list all the changes after bk-2.1.3 and send that list to
changes to get a changes style listing".  This is what Linus (and everyone
else) uses to generate release notes.
--
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.5 development

[Tom Rini]

On Fri, Feb 15, 2002 at 08:58:12AM -0800, Larry McVoy wrote:
>
> On Fri, Feb 15, 2002 at 11:11:57PM +1100, Paul Mackerras wrote:
> > The current limitations of BK mean that we will not be able to take
> > changesets directly from the linuxppc-2.5 tree and send them to
> > Linus.
>
> You can export changes as a patch and import them.

Which still isn't directly. :)  It will catch most of the problems, but
if you export a patch with new files from one tree, import into another
and pull back into the original, you have a file conflict, yes?

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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.5 development

[Larry McVoy]

On Fri, Feb 15, 2002 at 10:32:10AM -0700, Tom Rini wrote:
> On Fri, Feb 15, 2002 at 08:58:12AM -0800, Larry McVoy wrote:
> >
> > On Fri, Feb 15, 2002 at 11:11:57PM +1100, Paul Mackerras wrote:
> > > The current limitations of BK mean that we will not be able to take
> > > changesets directly from the linuxppc-2.5 tree and send them to
> > > Linus.
> >
> > You can export changes as a patch and import them.
>
> Which still isn't directly. :)  It will catch most of the problems, but
> if you export a patch with new files from one tree, import into another
> and pull back into the original, you have a file conflict, yes?

Yes, but that's not what we are talking about.  We're talking about
export/import from two "unrelated" BK trees.  You can't pull unrelated
trees at all.
--
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.5 development

[Tom Rini]

On Fri, Feb 15, 2002 at 09:33:50AM -0800, Larry McVoy wrote:
> On Fri, Feb 15, 2002 at 10:32:10AM -0700, Tom Rini wrote:
> > On Fri, Feb 15, 2002 at 08:58:12AM -0800, Larry McVoy wrote:
> > >
> > > On Fri, Feb 15, 2002 at 11:11:57PM +1100, Paul Mackerras wrote:
> > > > The current limitations of BK mean that we will not be able to take
> > > > changesets directly from the linuxppc-2.5 tree and send them to
> > > > Linus.
> > >
> > > You can export changes as a patch and import them.
> >
> > Which still isn't directly. :)  It will catch most of the problems, but
> > if you export a patch with new files from one tree, import into another
> > and pull back into the original, you have a file conflict, yes?
>
> Yes, but that's not what we are talking about.  We're talking about
> export/import from two "unrelated" BK trees.  You can't pull unrelated
> trees at all.

These are related trees.  For 2.5.x all of the PPC trees are related to
the official Linus 2.5.x bk tree.  Something like:
linux-2.5 -> {for-linus-*, linuxppc-2.5}.
Since linuxppc-2.5 and for-linus-ppc are both children of linux-2.5,
shouldn't they be related?

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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.5 development

[Larry McVoy]

> These are related trees.  For 2.5.x all of the PPC trees are related to
> the official Linus 2.5.x bk tree.  Something like:
> linux-2.5 -> {for-linus-*, linuxppc-2.5}.
> Since linuxppc-2.5 and for-linus-ppc are both children of linux-2.5,
> shouldn't they be related?

Yes, if they are all clones from the same original tree, they are all
related.  The way to tell is to run "bk identity" in each tree, if that
output is the same, you may pull between them.

I thought Paul was talking about taking changes from the tree Cort created
and putting it the tree Linus created.
--
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.5 development

[Tom Rini]

On Fri, Feb 15, 2002 at 10:44:33AM -0800, Larry McVoy wrote:
> > These are related trees.  For 2.5.x all of the PPC trees are related to
> > the official Linus 2.5.x bk tree.  Something like:
> > linux-2.5 -> {for-linus-*, linuxppc-2.5}.
> > Since linuxppc-2.5 and for-linus-ppc are both children of linux-2.5,
> > shouldn't they be related?
>
> Yes, if they are all clones from the same original tree, they are all
> related.  The way to tell is to run "bk identity" in each tree, if that
> output is the same, you may pull between them.
>
> I thought Paul was talking about taking changes from the tree Cort created
> and putting it the tree Linus created.

Nope.  We're still using those for 2.2 and 2.4, but the official tree
for 2.5 (since it makes our lives easier too :))

So are out of order changesets on the horizon?

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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.5 development

[Larry McVoy]

> So are out of order changesets on the horizon?

That depends on the height of the mountain on which you are standing.  :-)

They are a ways out, you'll need to change your workflow a bit until we
get them.  Jeff Garzik is going to take a pass at a Documentation/bk-howto
this weekend which will describe how he does it.  The reports from Linus
are that if you are willing to work like Jeff, it does save Linus quite a
bit of work.
--
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.5 development

[Stefan Jeglinski]

>The linux_2_5 and linuxppc_2_5 trees are
>dead, and I will remove them once we are sure we have all the changes
>from linuxppc_2_5 committed to the linuxppc-2.5 tree.

Will a mirror of this 2.5 tree still be available by rsync from
source.mvista.com?

Speaking of which, rsyncing the 2.4 tree at source.mvista.com shows
that it is at 2.4.18-rc2. Can I take this to mean that this bk-mirror
is also dead? If so, is there a replacement rsync source to keep up
with the bk tree?


Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.5 development

[Tom Rini]

On Tue, Feb 26, 2002 at 10:51:53AM -0500, Stefan Jeglinski wrote:
>
> >The linux_2_5 and linuxppc_2_5 trees are
> >dead, and I will remove them once we are sure we have all the changes
> >from linuxppc_2_5 committed to the linuxppc-2.5 tree.
>
> Will a mirror of this 2.5 tree still be available by rsync from
> source.mvista.com?

linuxppc-2.5 is currently up on rsync.

> Speaking of which, rsyncing the 2.4 tree at source.mvista.com shows
> that it is at 2.4.18-rc2. Can I take this to mean that this bk-mirror
> is also dead? If so, is there a replacement rsync source to keep up
> with the bk tree?

It'll be updated again shortly.

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

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/