Re: BK to CVS?

Progress.  I am telling cvs a "-ko" to keep keyword expansions as they
come in.

But I am still tripping over something that I either don't understand
in Bitkeeper, or Bitkeeper is misbehaving.  The following doesn't do
what I expect.


I started things up by doing:
- "bk clone", then
- "bk changes" to see what the most recent revision is, then
- a complete export of that rev, and put that in cvs as my starting
  point.

Then each day I have a script that does:
- "bk changes" to see the "before" rev,
- "bk pull" to get up to date,
- "bk changes" to see "after" rev,
- export of a patch between those two revs, apply that to my cvs.

The problem is that some of the patches fail because the cvs file
isn't in the state the patch expects.  Because I am still getting the
bugs out, we aren't doing any work in the cvs tree, only bk stuff is
going in there.

I did a new export from bk as of the latest "bk changes" rev and
compared that with an export from cvs.  (The idea being that beginning
dump + delta + delta + delta should equal ending dump.)  Yes, I get
some BK Id collisions that don't bother my daily patches, but I also
get a couple more files with substantial differences.  Is there
something wrong with my method?  Is there a likely problem with my
implementation?  Is Bitkeeper being buggy?


Thanks,

-kb, the Kent who is convinced he is getting close and so should soon
quit asking these annoying questions.

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

Kent Borg wrote:

Then each day I have a script that does:
- "bk changes" to see the "before" rev,
- "bk pull" to get up to date,
- "bk changes" to see "after" rev,
- export of a patch between those two revs, apply that to my cvs.

The problem is that some of the patches fail because the cvs file
isn't in the state the patch expects.  Because I am still getting the
bugs out, we aren't doing any work in the cvs tree, only bk stuff is
going in there.

Why don't you use the cvs vendor branch to do most of the work for you,
rather than generating deltas yourself?

Every day you'd get the latest release tree from BK and do a cvs import of
this into your local repository, followed by the cvs checkout -j -j and
cvs commit to merge the changes into the main trunk - CVS keeps track of
the state the BK repository was in when it was last imported.

If you do this right, this should only bring up problems in the checkout
-j -j stage when some locally committed change conflicts with an imported
change, which is something you'd have to fix manually anyway.

Oh, and BTW the instructions that cvs import prints out about doing the
cvs checkout -j -j aren't quite right, you should really use the release
tags you gave to cvs import rather than the :yesterday it recommends.

I can give more detail on this approach if you're interested - we don't
import the linuxppc tree, automate it or do it daily, but do have a
standard procedure for this kind of handling of externally managed code
with CVS.

- Andrew
--
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away.
- Antoine de Saint-Exupery

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

Hi, Andrew

I've ported Linux to a custom 8255-based board and now I'll have to deal with
creating and adapting device drivers for it. I realized that I should start
working with the linuxppc_2_4_devel BK tree, so I can contribute to it.

We internally use CVS nowadays, therefore I'm very interested in your
standard procedures to manage externally developed code.

Thanks in advance,

Ricardo Scop.
Digitel S/A, Brazil

On Friday 05 October 2001 18:48, Andrew Johnson wrote:

Kent Borg wrote:

quoted

Then each day I have a script that does:
- "bk changes" to see the "before" rev,
- "bk pull" to get up to date,
- "bk changes" to see "after" rev,
- export of a patch between those two revs, apply that to my cvs.

The problem is that some of the patches fail because the cvs file
isn't in the state the patch expects.  Because I am still getting the
bugs out, we aren't doing any work in the cvs tree, only bk stuff is
going in there.

Why don't you use the cvs vendor branch to do most of the work for you,
rather than generating deltas yourself?

Every day you'd get the latest release tree from BK and do a cvs import of
this into your local repository, followed by the cvs checkout -j -j and
cvs commit to merge the changes into the main trunk - CVS keeps track of
the state the BK repository was in when it was last imported.

If you do this right, this should only bring up problems in the checkout
-j -j stage when some locally committed change conflicts with an imported
change, which is something you'd have to fix manually anyway.

Oh, and BTW the instructions that cvs import prints out about doing the
cvs checkout -j -j aren't quite right, you should really use the release
tags you gave to cvs import rather than the :yesterday it recommends.

I can give more detail on this approach if you're interested - we don't
import the linuxppc tree, automate it or do it daily, but do have a
standard procedure for this kind of handling of externally managed code
with CVS.

- Andrew
--
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away.
- Antoine de Saint-Exupery

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

Hi, Dan

I can assure you that I intend to follow strictly your orders :^) when
submitting a patch to the linuxppc development tree.

However, I didn't tell the whole truth. Actually, I'm currently not using BK,
but instead rsyncing from the source.mvista.com mirror. Is that all right for
obtaining the current sources?

[  Thanks, Tom, I've just received your reply, I'll save your instructions
to use when and if my company allow us to use BK ]

BTW, I'm staring right now at the FCC driver for the MPC8260, looking for
MDIO support, and I can see that it's not compiled by default. Can you tell
me if it's operational? Our board has a Level One LTX960A PHY Transceiver
which is only working at 10 Mbps, and I would like to force it to 100 Mbps at
user's will.
('hope I'm not pushing you guys too much which parallel questions in a
reply...)

On Saturday 06 October 2001 05:25, Dan Malek wrote:

Ricardo Scop wrote:

quoted

We internally use CVS nowadays, therefore I'm very interested in your
standard procedures to manage externally developed code.

I would appreciate a patch against the current linuxppc_2_4_devel
tree.  Please pull the latest tree, do your work in that tree, and
then generate a patch using one of the convenient bk commands that
I hope Tom Rini can suggest :-).

It's quite time consuming to get patches that are "almost" up to
date and having to manually sort out the differences.  I could spend
24 hours a day just applying and testing patches sent to my personal
e-mail addresses.  It _really_ helps when they are up to date :-).

Thanks.


	-- Dan

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

Ricardo Scop wrote:

We internally use CVS nowadays, therefore I'm very interested in your
standard procedures to manage externally developed code.

I would appreciate a patch against the current linuxppc_2_4_devel
tree.  Please pull the latest tree, do your work in that tree, and
then generate a patch using one of the convenient bk commands that
I hope Tom Rini can suggest :-).

It's quite time consuming to get patches that are "almost" up to
date and having to manually sort out the differences.  I could spend
24 hours a day just applying and testing patches sent to my personal
e-mail addresses.  It _really_ helps when they are up to date :-).

Thanks.


	-- Dan

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

On Fri, Oct 05, 2001 at 10:25:22PM -0400, Dan Malek wrote:

Ricardo Scop wrote:

quoted

We internally use CVS nowadays, therefore I'm very interested in your
standard procedures to manage externally developed code.

I would appreciate a patch against the current linuxppc_2_4_devel
tree.  Please pull the latest tree, do your work in that tree, and
then generate a patch using one of the convenient bk commands that
I hope Tom Rini can suggest :-).

For uncommited (and this _won't_ catch new files):
bk -r diffs -u > foo
Or, if you commit everything and just want that rev:
bk export -tpatch -rRev (bk changes will show).
For multiple revs get the rev # of the latest pull of the external
source to yours.

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

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

On Fri, Oct 05, 2001 at 11:52:47PM +0300, Ricardo Scop wrote:

However, I didn't tell the whole truth. Actually, I'm currently not using BK,
but instead rsyncing from the source.mvista.com mirror. Is that all right for
obtaining the current sources?

Yes.  The rsync is usually only a few minutes behind the bk mirror
(which is a few minutes behind the master bk tree).

BTW, I'm staring right now at the FCC driver for the MPC8260, looking for
MDIO support, and I can see that it's not compiled by default. Can you tell
me if it's operational? Our board has a Level One LTX960A PHY Transceiver
which is only working at 10 Mbps, and I would like to force it to 100 Mbps at
user's will.

If you turn on CONFIG_USE_MDIO, it _may_ work.  You might have to add in
support for the LTX960A tho (only 970 and 971 are explicitly supported).

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

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

Ricardo Scop wrote:

I can assure you that I intend to follow strictly your orders :^)

Yeah, orders......There are (too many :-) other cooks if you would
rather send your recipe to them :-).

...... Is that all right for
obtaining the current sources?

Sure.

BTW, I'm staring right now at the FCC driver for the MPC8260,

There have been lots of cooks there recently as well.  I think the MDIO
enable is an artifact of something that was added for the 8xx configuration.
I guess I better look at this driver again and see if I can remember how
it attained its current state.  The MDIO has always been a challenge on
the 8260.  It is usually software managed, and when it works for one PHY
it seems to be broken for another.  Basically, it works for the last
person that added a PHY :-).

..... and I would like to force it to 100 Mbps at
user's will.

You are welcome to make it work :-).  I just let them autonegotiate the
highest performance and declare victory.  I'm sufficiently challenged
to just send bits......

Well that's interesting....I just discovered my tibook clock is set
incorrectly......sorry about that.


	-- Dan

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

Tom,

Saturday, October 06, 2001, 12:34:19 AM, you wrote:

TR> If you turn on CONFIG_USE_MDIO, it _may_ work.  You might have to add in
TR> support for the LTX960A tho (only 970 and 971 are explicitly supported).

Oh, I made two typos in a row! Actually, we are using the LXT970A chip,
which is an enhanced version from the 970, so I'll give it a try.

Thank you very much.

~ Scop


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

Hi Ricardo:

For PPCBoot, I made MII serial interface routines for the EST
(WindRiver) SBC8260 board.  This was a general purpose implementation,
customizable for different hardware by changing the #defines that
toggled the I/O port pins.  I also added a "mii" command that allows
you to read and write the MII registers from the command line.  I was
able to read and write the EnableSemi (Lucent) PHY, which is a "dongle"
type PHY provided by EST.  This could be helpful for you for poking
around in the PHY.  If your needs are not too complex, it may be
sufficient to initialize the PHY and let it run autonomously.

I submitted patches to Wolfgang, but it appears they have not been
rolled into the source yet.  If you want a patch, reply to my email
address and I'll send you one.

gvb


At 11:52 PM 10/5/01 +0300, Ricardo Scop wrote:

Hi, Dan

I can assure you that I intend to follow strictly your orders :^) when
submitting a patch to the linuxppc development tree.

However, I didn't tell the whole truth. Actually, I'm currently not
using BK,
but instead rsyncing from the source.mvista.com mirror. Is that all
right for
obtaining the current sources?

[  Thanks, Tom, I've just received your reply, I'll save your instructions
to use when and if my company allow us to use BK ]

BTW, I'm staring right now at the FCC driver for the MPC8260, looking for
MDIO support, and I can see that it's not compiled by default. Can you
tell
me if it's operational? Our board has a Level One LTX960A PHY Transceiver
which is only working at 10 Mbps, and I would like to force it to 100
Mbps at
user's will.
('hope I'm not pushing you guys too much which parallel questions in a
reply...)

On Saturday 06 October 2001 05:25, Dan Malek wrote:

quoted

Ricardo Scop wrote:

quoted

We internally use CVS nowadays, therefore I'm very interested in your
standard procedures to manage externally developed code.

I would appreciate a patch against the current linuxppc_2_4_devel
tree.  Please pull the latest tree, do your work in that tree, and
then generate a patch using one of the convenient bk commands that
I hope Tom Rini can suggest :-).

It's quite time consuming to get patches that are "almost" up to
date and having to manually sort out the differences.  I could spend
24 hours a day just applying and testing patches sent to my personal
e-mail addresses.  It _really_ helps when they are up to date :-).

Thanks.


      -- Dan

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