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
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
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
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
[ 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
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_
[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
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
[ 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
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
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
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
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
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
[ 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
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
[ 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
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
[ 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
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
[ 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
[ 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
[ 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
[ 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
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
[ 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
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.
[ 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
[ 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
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
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
[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
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
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 (?)
[ 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
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
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...'
[ 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
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
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.
[ 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
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
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
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
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
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
46 matches
Mail list logo
