BK to CVS?

BK to CVS?

[Kent Borg]

We use cvs internally and I am trying to get all the daily patches out
of Bitkeeper and into a cvs module.  Are others doing this?  Is it
reasonable?  If so, how are you doing it?

I tried using "bk export" to generate a patch file I could apply to my
cvs tree, but there are Id keywords that cvs honored the last time
around making the patch not apply properly.

I noticed in the documentation for export that it apparently only
honors the "-k" switch for killing keywords when doing a complete
export--so I tried that intending to make my patch from two complete
Linux trees.  Except the -k didn't work.  The Id contents are still
there in the exported files.

Finally, I tried writing some perl to post-process the "bk export"
patch to remove the simple Id changes.  Cool, but bunches of files, at
least in yesterday's pull, have changes up near the Id and so are part
of the same patch hunk, and catching that in a perl script is going to
be a lot harder.


How do the rest of you use Bitkeeper with other source control
systems?  (Or do you?)


Thanks,

-kb, the Kent who is coming to hate keywords in source code control
systems.

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

Re: BK to CVS?

[Tom Rini]

On Wed, Oct 03, 2001 at 01:05:59PM -0400, Kent Borg wrote:

> We use cvs internally and I am trying to get all the daily patches out
> of Bitkeeper and into a cvs module.  Are others doing this?  Is it
> reasonable?  If so, how are you doing it?

Doing this daily isn't too horrid.  Use the rsync version and tag
a tree daily.  Thats more or less what I do.

> I tried using "bk export" to generate a patch file I could apply to my
> cvs tree, but there are Id keywords that cvs honored the last time
> around making the patch not apply properly.

Yeap.  One thing you can try is to un-export the keywords first.  Ie
change them back into BK Id: %x% %..%

> Finally, I tried writing some perl to post-process the "bk export"
> patch to remove the simple Id changes.  Cool, but bunches of files, at
> least in yesterday's pull, have changes up near the Id and so are part
> of the same patch hunk, and catching that in a perl script is going to
> be a lot harder.

Smaller hunks and change 'em back into the unexported form?

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

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

Re: BK to CVS?

[Kent Borg]

On Wed, Oct 03, 2001 at 11:32:45AM -0700, Tom Rini wrote:
> Doing this daily isn't too horrid.  Use the rsync version and tag
> a tree daily.  Thats more or less what I do.

I might switch to that.

But won't I still have a problem of our cvs expanding keywords
breaking the next patch that gets too near them?

> Yeap.  One thing you can try is to un-export the keywords first.  Ie
> change them back into BK Id: %x% %..%

I don't understand.

> Smaller hunks and change 'em back into the unexported form?

Again I don't think I understand what you mean by "unexported form".


Right now I am burning plenty of computrons and rattling the disk a
lot (let's hear it for otherwise idle machines) by exporting two
complete trees, running a slow perl script over both to remove
expansions of dollar-Id, and now dollar-Revision, make my own diff
-Nru of that, and then I guess I will have to patch by hand a zillion
annoying recent changes to the placement dollar-Id in sparc64 files.
And then I will tackle whatever I discover is still not patching after
my modified perl script finishes running.

I am starting to think that trying to run a shadow source code
controlled repository is a mistake.  Am I dragging along unadvisable
mental baggage from the old days of developing proprietary code?  Do I
need to take a deep breath here, hold my nose, have faith in The
Source, and leap??  Am I foolishly fighting Bitkeeper by trying to
stick with cvs internally?  Do I need to just give in on Bitkeeper?


Thanks,


-kb, the Kent who is coming to hate source code control system
keywords with more and more authority each day.

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

Re: BK to CVS?

[Tom Rini]

On Thu, Oct 04, 2001 at 09:25:12AM -0400, Kent Borg wrote:
>
> On Wed, Oct 03, 2001 at 11:32:45AM -0700, Tom Rini wrote:
> > Doing this daily isn't too horrid.  Use the rsync version and tag
> > a tree daily.  Thats more or less what I do.
>
> I might switch to that.
>
> But won't I still have a problem of our cvs expanding keywords
> breaking the next patch that gets too near them?
>
> > Yeap.  One thing you can try is to un-export the keywords first.  Ie
> > change them back into BK Id: %x% %..%
>
> I don't understand.

Okay.  Before you import from say rsync to CVS, go and change all of the
PPC files from:
BK Id: SCCS/s.setup.c 1.73 10/02/01 10:06:27 paulus
to:
BK Id: %F% %I% %G% %U% %#%

And then import.  The keyword section will always be the same, and CVS
should be quite.  I haven't tried this yet tho.

> > Smaller hunks and change 'em back into the unexported form?
>
> Again I don't think I understand what you mean by "unexported form".

Oh.  BK tags, which CVS chokes on have expanded and unxpanded forms
just like the CVS ones.

> Right now I am burning plenty of computrons and rattling the disk a
> lot (let's hear it for otherwise idle machines) by exporting two
> complete trees, running a slow perl script over both to remove
> expansions of dollar-Id, and now dollar-Revision, make my own diff
> -Nru of that, and then I guess I will have to patch by hand a zillion
> annoying recent changes to the placement dollar-Id in sparc64 files.
> And then I will tackle whatever I discover is still not patching after
> my modified perl script finishes running.

Ah, you're being too zellous in your attempts.  If you do -ko on the
import of files like sparc64, it will treat the $Id$ stuff as normal text.
This doesn't work on the BK ids which is chokes on anyhow.  The other
thing I do, since this isn't fully automated, is if files end up
being unhappy after CVS merge is to cat the original over 'em.  This
only works on files I don't change tho. :)

> I am starting to think that trying to run a shadow source code
> controlled repository is a mistake.  Am I dragging along unadvisable
> mental baggage from the old days of developing proprietary code?  Do I
> need to take a deep breath here, hold my nose, have faith in The
> Source, and leap??  Am I foolishly fighting Bitkeeper by trying to
> stick with cvs internally?  Do I need to just give in on Bitkeeper?

That's a bit for another 'discussion'.

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

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

Re: BK to CVS?

[Kent Borg]

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/

Re: BK to CVS?

[Andrew Johnson]

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/

Re: BK to CVS?

[Ricardo Scop]

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:
> > 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/

Re: BK to CVS?

[Kent Borg]

On Fri, Oct 05, 2001 at 10:48:31AM -0500, Andrew Johnson wrote:
> Why don't you use the cvs vendor branch to do most of the work for you,
> rather than generating deltas yourself?

And so do complete exports?  I didn't start out that way because I am
running BK on an underpowered machine and complete exports are slow.
Aso, where I work there are stupid security policies that force me to
mail between that real internet connection that can do BK and the
broken corporate network, and mailing whole kernels seems fraught with
problems.

Your suggestion seesm to imply that complete exports are more reliable
than deltas.  True?


Thanks,

-kb, the Kent who is close to conclusion, if for no other reason,
because he has to get some real work done.

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

Re: BK to CVS?

[Andrew Johnson]

Kent Borg wrote:
>
> And so do complete exports?  I didn't start out that way because I am
> running BK on an underpowered machine and complete exports are slow.
> Aso, where I work there are stupid security policies that force me to
> mail between that real internet connection that can do BK and the
> broken corporate network, and mailing whole kernels seems fraught with
> problems.

Can't you persuade your security people to allow you to make an incoming
ssh connection to your repository machine from your BK machine?  If so
then you shouldn't need to use mail, but if not then your idea of mailing
patches might be better if you can get it to work.  On the BK side you
probably don't have to do a complete export every day, just an update (or
whatever the BK equivalent is, I only know CVS...) and then you do a cvs
import of that tree.

> Your suggestion seesm to imply that complete exports are more reliable
> than deltas.  True?

If that's a question about BK I can't answer it as I've never used BK, so
don't make that implication.  I didn't really look at precisely what
you're doing with the BK stuff (because I don't understand the
terminology), I just thought about what you're trying to accomplish, which
is basically what cvs import does.

Sorry if that was a wild goose chase...

- 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/

Re: BK to CVS? + MDIO

[Ricardo Scop]

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:
> > 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/

Re: BK to CVS?

[Dan Malek]

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/

Re: BK to CVS?

[Tom Rini]

On Fri, Oct 05, 2001 at 10:25:22PM -0400, Dan Malek wrote:
>
> 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 :-).

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/

Re: BK to CVS? + MDIO

[Tom Rini]

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/

Re: BK to CVS? + MDIO

[Dan Malek]

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/

Re[2]: BK to CVS? + MDIO

[Ricardo Scop]

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/

Re: BK to CVS? + MDIO

[Jerry Van Baren]

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:
> > 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/

Re: BK to CVS? + MDIO

[Wolfgang Denk]

In message <4.3.2.20011008074637.00c64340@falcon.si.com> you wrote:
>
> 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.

Sorry for the delay, but it's my first day  in  the  office  after  3
weeks  of vacation, and I'm still trying to figure out where to start
working on all the things that piled up...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
C makes it easy for you to shoot yourself in the foot. C++ makes that
harder, but when you do, it blows away your whole leg.
                                                 -- Bjarne Stroustrup

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