[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strategy for tracking 3rd party source.
From: |
Mark D. Baushke |
Subject: |
Re: Strategy for tracking 3rd party source. |
Date: |
Tue, 30 Aug 2005 23:55:27 -0700 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
address@hidden writes:
> I need to track some 3rd party source code, in this case the Linux
> kernel and then manage our local modifications to the kernel (don't
> worry, GPL is being respected). I've run into an issue where an
> import updates files on the HEAD and I'm not sure if I want this to
> happen.
>
> For example, I import a kernel with the vendor tag of KERNEL_ORG and a
> release tag of LINUX_2_6_12. I add my local changes and commit them.
> All is well.
>
> There are 2 projects that pull the HEAD from this module into their
> projects, this works pretty well. The problem arises when I import a
> new version of the kernel, say LINUX_2_6_13. Its possible that it
> could be a while (couple of days) before HEAD is working again - not
> an ideal situation for the projects that depend on this module.
>
> What I am thinking of doing is reserving HEAD for the 3rd party source
> and then making a branch, MYBRANCH. The other projects can then pull
> from MYBRANCH (our internal HEAD so to speak), I can then do the
> import, merge the changes into MYBRANCH and commit the working code
> into MYBRANCH after its working. That way MYBRANCH is always usable.
>
> Is this a reasonable approach?
Your outlined method should work.
> Is there a better way?
I believe you want the 'cvs import -X' feature provided by Chris
Demetriou or you want to use his 'cvsimport_killnew' script.
Read http://lists.gnu.org/archive/html/bug-cvs/2004-06/msg00173.html
This feature was added to cvs 1.12.10. The latest CVS release is cvs
1.12.12.
-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFDFVRfCg7APGsDnFERAvslAKD2HF+LS1G1+omohoRCKZ64qLvUCgCg0CxB
bdph92h+d0GvKYHEOPxWqgo=
=RXEz
-----END PGP SIGNATURE-----