From: Ricardo Scop <scop@digitel.com.br>
To: Andrew Johnson <anj@aps.anl.gov>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: BK to CVS?
Date: Fri, 5 Oct 2001 19:04:44 +0300 [thread overview]
Message-ID: <01100519044401.01029@scop.digitel.com.br> (raw)
In-Reply-To: <3BBDD64F.97B0057B@aps.anl.gov>
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/
next prev parent reply other threads:[~2001-10-05 16:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-03 17:05 BK to CVS? Kent Borg
2001-10-03 18:32 ` Tom Rini
2001-10-04 13:25 ` Kent Borg
2001-10-04 20:29 ` Tom Rini
2001-10-05 15:11 ` Kent Borg
2001-10-05 15:48 ` Andrew Johnson
2001-10-05 16:04 ` Ricardo Scop [this message]
2001-10-06 2:25 ` Dan Malek
2001-10-05 20:52 ` BK to CVS? + MDIO Ricardo Scop
2001-10-06 3:34 ` Tom Rini
2001-10-06 3:42 ` Re[2]: " Ricardo Scop
2001-10-06 3:41 ` Dan Malek
2001-10-08 12:01 ` Jerry Van Baren
2001-10-08 13:06 ` Wolfgang Denk
2001-10-06 2:43 ` BK to CVS? Tom Rini
2001-10-05 16:23 ` Kent Borg
2001-10-05 16:42 ` Andrew Johnson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01100519044401.01029@scop.digitel.com.br \
--to=scop@digitel.com.br \
--cc=anj@aps.anl.gov \
--cc=linuxppc-embedded@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).