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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.