[Q] Vendor Branches and Updates

2004-03-19 Thread John Muller
Title: [Q] Vendor Branches and Updates Supposed we have two files from a module (file1 and file2). file1 has been locally modified, but file2 has not. If I attempt to merge both of these files (in one import command). What happens to file1? 1) Does it become the head revision

RE: [Q] Vendor Branches and Updates

2004-03-19 Thread Jim.Hyslop
John Muller wrote: Supposed we have two files from a module (file1 and file2). file1 has been locally modified, but file2 has not. If I attempt to merge both of these files (in one import command). What happens to file1? 1) Does it become the head revision automatically? 2) Or does it

Re: [Q] Vendor Branches and Updates

2004-03-19 Thread Larry Jones
John Muller writes: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! If I attempt to merge both of these files

Vendor Branches

2003-01-04 Thread John Birtley
Title: Message I wonder if anybody can help me with the following problem regarding multiple vendor branches. I regularly receive code drops from vendors in the form of tarballs. I want to untar them and then `cvs import' to the appropriate vendor branch. Once they are on the vendor

Re: Vendor Branches

2003-01-04 Thread Greg A. Woods
[ On Saturday, January 4, 2003 at 20:05:46 (-), John Birtley wrote: ] Subject: Vendor Branches The problem is that I want to be able to copy the latest version on the vendor branch to the latest version on the INTEGRATION branch, since all integration testing and tagging is to be done

Re: Vendor Branches

2003-01-04 Thread Fredrik Wendt
I have a simple what about this I'd like to comment on, regarding the expressed rich text e-mail is always bad-attitude. In this specific case, I think it _is_ ok to use stylized e-mail, since the diagrams would be rendered with MUA:s showing mail with non-fixed width characters. (It _is_

RE: Vendor Branches

2003-01-04 Thread John Birtley
[mailto:[EMAIL PROTECTED]] Sent: 04 January 2003 23:25 To: John Birtley Cc: [EMAIL PROTECTED] Subject: Re: Vendor Branches [ On Saturday, January 4, 2003 at 20:05:46 (-), John Birtley wrote: ] Subject: Vendor Branches The problem is that I want to be able to copy the latest version

Re: Vendor Branches

2003-01-04 Thread Kaz Kylheku
On Sat, 4 Jan 2003, John Birtley wrote: Date: Sat, 4 Jan 2003 20:05:46 - From: John Birtley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Vendor Branches I wonder if anybody can help me with the following problem regarding multiple vendor branches. Meta-CVS has a feature like

Re: Vendor Branches

2003-01-04 Thread Greg A. Woods
[ On Sunday, January 5, 2003 at 02:43:44 (+0100), Fredrik Wendt wrote: ] Subject: Re: Vendor Branches I have a simple what about this I'd like to comment on, regarding the expressed rich text e-mail is always bad-attitude. In this specific case, I think it _is_ ok to use stylized e-mail

Vendor branches, imports and checkouts

2002-12-16 Thread Ross Patterson
I've just been surprised by cvs import, and I'm having a hard time deciding who's wrong and how to best approach the problem. What's a poor geek to do? We've got a CVS repository here that contains a modified version of the NetBSD kernel. We built it by importing the source as a vendor branch

Re: Vendor branches, imports and checkouts

2002-12-16 Thread Larry Jones
Ross Patterson writes: Have I misunderstood the interactions between import, checkout and update? Yes. Please re-read the section of the manual on tracking third-party sources: http://www.cvshome.org/docs/manual/cvs_13.html#SEC104 Pay particular attention to the details about the

Re: Vendor branches, imports and checkouts

2002-12-16 Thread Ross Patterson
On Monday 16 December 2002 11:29 am, Larry Jones wrote: Ross Patterson writes: Have I misunderstood the interactions between import, checkout and update? Yes. Please re-read the section of the manual on tracking third-party sources: So I guess I should have read: When you import

Re: Vendor branches and head revisions

2002-05-20 Thread Mark A. Flacy
Why not simply add an empty comment to each file in the trunk at the very beginning? That way they are all modified. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs

Vendor branches and head revisions

2002-05-17 Thread Jouni Heikniemi
from the various sources. I'd greatly appreciate corrections and proposals for better approaches. - The best way around the mentioned problem is to use normal branches - Import doesn't work properly on non-vendor branches - Therefore the updates should be done by checking out a fresh sandbox

Re: Vendor branches and head revisions

2002-05-17 Thread Greg A. Woods
[ On Friday, May 17, 2002 at 14:33:34 (+0300), Jouni Heikniemi wrote: ] Subject: Vendor branches and head revisions I've tried browsing the list archive, but couldn't find a comprehensive answer on this neither in the archives nor the documents. So I'll just ask: We have the normal

Re: Vendor branches and head revisions

2002-05-17 Thread Eric Siegerman
On Fri, May 17, 2002 at 11:52:39AM -0400, Greg A. Woods wrote: [ On Friday, May 17, 2002 at 14:33:34 (+0300), Jouni Heikniemi wrote: ] - Therefore the updates should be done by checking out a fresh sandbox from the vendor branch (really a normal one), copying the modified files over

Re: Vendor branches and head revisions

2002-05-17 Thread Greg A. Woods
[ On Friday, May 17, 2002 at 13:14:38 (-0400), Eric Siegerman wrote: ] Subject: Re: Vendor branches and head revisions Or delete them all in advance: - Check out the fresh sandbox mentioned above, from the pseudo-vendor branch - Delete everything that isn't a CVS admin file

Merging multiple vendor branches

2002-04-01 Thread Danial
Hi, I'm trying to merge a tree into a branch but am having some problems. First of all, I have an already existing tree called X which I want to merge into Branch_X. (See diagram below) The developers will commit their code in X and I will do the merges into Branch_X. Main is a new tree which

Re: Merging multiple vendor branches

2002-04-01 Thread Greg A. Woods
[ On , April 1, 2002 at 10:47:58 (-0800), Danial wrote: ] Subject: Merging multiple vendor branches This is what I tried to do but it will not work: First, I imported the two trees using the multiple vendor importing method (Section 13.6 of the Cederqvist manual): cvs import -m Main

Re: importing vendor branches

2001-07-13 Thread Michael A. Fetterman
entertaining, but you can solve it pretty well with a simple naming convention. The script is particularly designed to work correctly in the presence of multiple cvs vendor branches (ala cvs import -b), but does nothing to fix the brain dead requirements of that switch for a numeric branch number

Re: importing vendor branches

2001-07-13 Thread Greg A. Woods
[ On Friday, July 13, 2001 at 11:01:11 (-0700), Michael A. Fetterman wrote: ] Subject: Re: importing vendor branches There's no need to do anything special for these cases, as the current cvs import doesn't do anything terribly evil here. The absence of a releasetag on the vendor branch

Re: importing vendor branches

2001-07-12 Thread Greg A. Woods
[ On Thursday, July 12, 2001 at 12:56:11 (-0700), Michael A. Fetterman wrote: ] Subject: Re: importing vendor branches One proposed fix (for #1 and #2 only): For each file newly created by a cvs import, do a cvs delete on that file. That will cause its default branch to be set back

Re: importing vendor branches

2001-05-11 Thread Greg A. Woods
[ On Friday, May 4, 2001 at 15:13:18 (-0400), Larry Jones wrote: ] Subject: Re: importing vendor branches Greg A. Woods writes: I still don't see the problem here. If everyone who might do a checkout reads at least the subject lines of the mail from loginfo they'll know when

Re: importing vendor branches

2001-05-11 Thread Greg A. Woods
[ On , May 4, 2001 at 18:28:36 (-0400), Laine Stump wrote: ] Subject: Re: importing vendor branches Right. And not all merges are simple 10 minute deals, and not all repositories are used by less than 10 people. Imagine some significant portion of 100 engineers breathing down your neck

Multiple vendor branches?

2001-05-08 Thread Daniel Horner
Title: Multiple vendor branches? Hi, I've got two external branches of the same code from different vendors, call them A and B. I've imported them as described in TFM under Multiple Vendor Branches. Development has actively continued on the source from A A and B have different

Re: Multiple vendor branches?

2001-05-08 Thread Greg A. Woods
[ On Tuesday, May 8, 2001 at 17:07:10 (-0400), Daniel Horner wrote: ] Subject: Multiple vendor branches? I've got two external branches of the same code from different vendors, call them A and B. I've imported them as described in TFM under Multiple Vendor Branches. Development has actively

Re: importing vendor branches

2001-05-04 Thread Laine Stump
David L. Martin [EMAIL PROTECTED] writes: When a new RCS file is created as a result of cvs import, the RCS archive's default branch is 1.1.1. When/If the first local modification is committed, the default branch becomes blank (= the trunk). See the output of cvs log in the Branch: field.

Re: importing vendor branches

2001-05-04 Thread Greg A. Woods
[ On Friday, May 4, 2001 at 00:58:52 (-0500), David L. Martin wrote: ] Subject: Re: importing vendor branches To avoid this mess, you might consider moving your development from the trunk to a branch. You'd be guaranteed that a vendor import would not affect the contents of your development

Re: importing vendor branches

2001-05-04 Thread Greg A. Woods
[ On , May 4, 2001 at 12:22:16 (-0400), Laine Stump wrote: ] Subject: Re: importing vendor branches Another way to fix this is to just force a null commit (new revision, but 0 lines changed) on the trunk of each new file right after it is initially imported. That works too, but potentially

Re: importing vendor branches

2001-05-04 Thread Larry Jones
Greg A. Woods writes: I still don't see the problem here. If everyone who might do a checkout reads at least the subject lines of the mail from loginfo they'll know when an import was done, and in what module, and be able to avoid doing a fresh checkout that might result in an inconsistent

Re: importing vendor branches

2001-05-04 Thread Rickard Parker
I want to thank the previous recent posters to this thread. Their advice came just at the time I was needing to import some third party software and also checkin in a tree of software that we developed. In particular I want to thank David Martin for his suggestion of To make update -A retrieve

Re: importing vendor branches

2001-05-04 Thread Laine Stump
[EMAIL PROTECTED] (Larry Jones) writes: Greg A. Woods writes: I still don't see the problem here. If everyone who might do a checkout reads at least the subject lines of the mail from loginfo they'll know when an import was done, and in what module, and be able to avoid doing a

Re: importing vendor branches

2001-05-03 Thread Fergus Henderson
On 12-Apr-2001, Larry Jones [EMAIL PROTECTED] wrote: Fergus Henderson writes: The reason that this broke things is that `cvs checkout' was checking out inconsistent versions of different files. After the import, some files -- those which we had not modified -- now had revision 1.1.2

Re: importing vendor branches

2001-05-03 Thread Nils Jakobson
I've also encountered this problem, as far as I've verified it looks like this: when I do unconditional checkout, it always does get the latest revision no matter from which branch (like 1.1.1.1 right after import). When I update it updates the main trunk since it _stays_ there by default (?)

Re: importing vendor branches

2001-05-03 Thread Greg A. Woods
[ On Thursday, May 3, 2001 at 16:58:14 (+0300), Nils Jakobson wrote: ] Subject: Re: importing vendor branches I've also encountered this problem, as far as I've verified it looks like this: when I do unconditional checkout, it always does get the latest revision no matter from which branch

Re: importing vendor branches

2001-05-03 Thread Fergus Henderson
On 03-May-2001, Greg A. Woods [EMAIL PROTECTED] wrote: [ On Thursday, May 3, 2001 at 16:58:14 (+0300), Nils Jakobson wrote: ] Subject: Re: importing vendor branches I've also encountered this problem, as far as I've verified it looks like this: when I do unconditional checkout

Re: importing vendor branches

2001-05-03 Thread Fergus Henderson
On 03-May-2001, Nils Jakobson [EMAIL PROTECTED] wrote: My solution is never work with unconditional checkouts from very beginning, I simply put branch 1 in the checkout options and it stays on the main line. Just to clarify: are you suggesting the use of `cvs checkout -r1 modules...'

Re: importing vendor branches

2001-05-03 Thread Greg A. Woods
[ On Friday, May 4, 2001 at 06:23:02 (+1000), Fergus Henderson wrote: ] Subject: Re: importing vendor branches But nevertheless, this behaviour is BAD - Broken As Designed. Any command whose default behaviour leaves the main branch of the repository in an inconsistent state is a problem

Re: importing vendor branches

2001-05-03 Thread Larry Jones
Greg A. Woods writes: There is nothing really inconsistent about the state of the repository after a cvs import. Fergus's complaint is that anyone checking out the head of the tree between the time of the import and the time the merge is committed gets the newly imported version of files

RE: importing vendor branches

2001-05-03 Thread Jerry Nairn
From: Fergus Henderson [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 1:28 PM On 03-May-2001, Nils Jakobson [EMAIL PROTECTED] wrote: My solution is never work with unconditional checkouts from very beginning, I simply put branch 1 in the checkout options and it stays on the main line.

Re: importing vendor branches

2001-05-03 Thread Greg A. Woods
[ On Thursday, May 3, 2001 at 18:33:17 (-0400), Larry Jones wrote: ] Subject: Re: importing vendor branches Fergus's complaint is that anyone checking out the head of the tree between the time of the import and the time the merge is committed gets the newly imported version of files

Re: importing vendor branches

2001-05-03 Thread David L. Martin
Fergus Henderson writes: The reason that this broke things is that `cvs checkout' was checking out inconsistent versions of different files. After the import, some files -- those which we had not modified -- now had revision 1.1.2 on the vendor branch, and only 1.1 on the main

importing vendor branches

2001-04-12 Thread Fergus Henderson
I recently did a `cvs import' to update the version of a third-party package that we use in our product. Unfortunately, this import immediately broke our repository; the automated cron tests started failing, developers on the other side of the planet complained because they couldn't build from

Re: importing vendor branches

2001-04-12 Thread Larry Jones
Fergus Henderson writes: The reason that this broke things is that `cvs checkout' was checking out inconsistent versions of different files. After the import, some files -- those which we had not modified -- now had revision 1.1.2 on the vendor branch, and only 1.1 on the main branch, and

Vendor branches, tracking sources and creating patches

2000-12-20 Thread Ross Burton
Hi, I think I have this sorted out in my head but I need to run it past some people who are "in the know", so to speak. We are planning to create a new GCC backend, and as there will be multiple developers it all needs to be in CVS. We need to be able to: 1) update the version of gcc we are

Re: Vendor branches, tracking sources and creating patches

2000-12-20 Thread Eric Siegerman
On Wed, Dec 20, 2000 at 05:37:44PM -, Ross Burton wrote: [they need to use CVS to track the GCC distribution while making local changes] I think this can be achieved if we take, for example, gcc 2.95.2 and import into our tree as such: tar zxvf gcc-2.95.2.tar.gz ; cd gcc-2.95.2 cvs