There's only one problem though How do you handle removal and then
subsequent re-addition of a file on the vendor branch? I don't think
your current script does that from what I can understand of it on one
quick read How about if there were previous local changes to a
removed
[ 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
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
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
22 matches
Mail list logo
