On Fri, Mar 23, 2001 at 03:41:12PM -0500, Derek R. Price wrote:
> Eric Siegerman wrote:
> > [if] the ,v file has an appropriate vendor branch, but the latest
> > revision on that branch is marked "dead", then of course the new
> > release tag should be added to that dead revision
>
> No it shouldn
Eric wrote:
>Note that if all of these conditions are met except the last one,
>ie. the ,v file has an appropriate vendor branch, but the latest
>revision on that branch is marked "dead", then of course the new
>release tag should be added to that dead revision -- as happens
>now for an unchanged
Eric Siegerman wrote:
> Note that if all of these conditions are met except the last one,
> ie. the ,v file has an appropriate vendor branch, but the latest
> revision on that branch is marked "dead", then of course the new
> release tag should be added to that dead revision -- as happens
> now f
Eric Siegerman wrote:
> On Fri, Mar 23, 2001 at 09:19:32AM -0500, Derek R. Price wrote:
> > Basically, import would have to look up the tip of the vendor branch
> > before execution to obtain the list of files present during the last
> > import.
>
> Not "before execution". Instead, "import" turn
On Fri, Mar 23, 2001 at 09:19:32AM -0500, Derek R. Price wrote:
> Nathan Herring wrote:
> > Import knows the name and branch version of the vendor branch, has a
> > list of files to import, and has a list of files already in the
> > repository. This is all it needs to know. Now use the following
>
On Thu, Mar 22, 2001 at 10:30:19PM -0800, Nathan Herring wrote:
> Larry writes:
> >How is import supposed to know to do that, though?
>
> IF import file does not exist,
> AND repository file does exist,
> AND repository file has a branch with the same name as the vendor-tag
> argument
> AN
Nathan Herring wrote:
> Larry writes:
> >How is import supposed to know to do that, though?
>
> Import knows the name and branch version of the vendor branch, has a
> list of files to import, and has a list of files already in the
> repository. This is all it needs to know. Now use the following
r1 tag, and so CVS assumes it wasn't part of this vendor's import
and leaves it alone.
-Original Message-
From: Larry Jones [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 22, 2001 8:59 PM
To: Eric Siegerman
Cc: [EMAIL PROTECTED]
Subject: Re: Reimporting vendor projects where i
Eric Siegerman writes:
>
> If, as someone suggested, "import" were to check in a "dead"
> revision on the vendor branch, I presume both versions would
> work.
How is import supposed to know to do that, though?
-Larry Jones
Aw Mom, you act like I'm not even wearing a bungee cord! -- Calvin
___
On Thu, Mar 22, 2001 at 05:18:12PM -0500, Larry Jones wrote:
> You have to use the new
> release tag (it's the absence of that tag that indicates that the file
> should be deleted). So, instead of suggesting -jNET:yesterday -jNET,
> CVS should be suggesting -jNET:yesterday -jSECOND, for example.
Title: RE: Reimporting vendor projects where items have been deleted
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, March 22, 2001 2:18 PM
>should be deleted). So, instead of suggesting -jNET:yesterday -jNET,
>CVS should be suggesting -jNET:yesterday -
Laine Stump writes:
>
> If you want to modify your statement to say "Doing a merge using the
> tags placed on the branch at the time of the last two imports" (or
> something similar), we'll be in complete agreement, but currently the
> merge that cvs suggests does nothing of the sort, so either y
[EMAIL PROTECTED] (Larry Jones) writes:
> Laine Stump writes:
> >
> > That's great, but your example doesn't use the tags normally suggested
> > in the results of imports, eg "-j NET:yesterday -j NET" (which in this
> > case wouldn't work anyway because it had been less than a day between
> > im
Laine Stump writes:
>
> That's great, but your example doesn't use the tags normally suggested
> in the results of imports, eg "-j NET:yesterday -j NET" (which in this
> case wouldn't work anyway because it had been less than a day between
> imports, but that's beside the point).
No, but it show
[EMAIL PROTECTED] (Larry Jones) writes:
> [ example of cvs import followed by merge auto-deleting files ]
That's great, but your example doesn't use the tags normally suggested
in the results of imports, eg "-j NET:yesterday -j NET" (which in this
case wouldn't work anyway because it had been les
Laine Stump writes:
>
> This was the first import in about 6 months. All the differences in
> files, and new files, were merged correctly. However, your message had
> indicated that file deletions would also be marked when I did the
> merge; this was not the case.
bash-2.02$ echo file1 >
[EMAIL PROTECTED] (Larry Jones) writes:
> Laine Stump writes:
> >
> > I'm glad this message came by again - I just did an import and saw the
> > that the behavior described by Larry below did not occur. Nothing is
> > marked for deletion by CVS either during the import or during
> > execution of
Laine Stump writes:
>
> I'm glad this message came by again - I just did an import and saw the
> that the behavior described by Larry below did not occur. Nothing is
> marked for deletion by CVS either during the import or during
> execution of the suggested "merging checkout" afterwards.
The su
Eric Siegerman wrote:
>On Tue, Mar 20, 2001 at 05:20:25PM -0800, Stephen Rasku wrote:
>> Nathan Herring wrote:
>> >I'd like to have the option on successive imports to mark as
deleted any
>> >files that previously existed on that vendor branch that are not
in the
>> >import.
>>
>> I don't see
-Original Message-
From: Stephen Rasku [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 5:20 PM
To: Nathan Herring; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Reimporting vendor projects where items have been deleted
Nathan Herring wrote:
>
>Is there some place to make f
On Tue, Mar 20, 2001 at 05:20:25PM -0800, Stephen Rasku wrote:
> Nathan Herring wrote:
> >I'd like to have the option on successive imports to mark as deleted any
> >files that previously existed on that vendor branch that are not in the
> >import.
>
> I don't see why this is necessary. If you
I'm glad this message came by again - I just did an import and saw the
that the behavior described by Larry below did not occur. Nothing is
marked for deletion by CVS either during the import or during
execution of the suggested "merging checkout" afterwards.
Actually, there are times when this b
Nathan Herring wrote:
>
>Is there some place to make feature requests such as this one?
>
>I'd like to have the option on successive imports to mark as deleted
any
>files that previously existed on that vendor branch that are not in
the
>import.
>
>To wit,
>
>cvs import -m "version 1" themodule
1.2 marking the file as deleted.
Thx,
nh
-Original Message-
From: Nathan Herring
Sent: Sunday, February 25, 2001 2:43 PM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Subject: RE: Reimporting vendor projects where items have been deleted
Right, but you end up with version
[EMAIL PROTECTED]
Subject: Re: Reimporting vendor projects where items have been deleted
[EMAIL PROTECTED] writes:
>
> If I am importing a vendor project for the second or subsequent times
> on the same vendor branch, how can I mark the files that no longer
> exist in the vendor projects a
[EMAIL PROTECTED] writes:
>
> If I am importing a vendor project for the second or subsequent times
> on the same vendor branch, how can I mark the files that no longer
> exist in the vendor projects as deleted on the vendor branch?
Doing the merge that CVS suggests when there are conflicts (e
If I am importing a vendor project for the second or subsequent times
on the same vendor branch, how can I mark the files that no longer
exist in the vendor projects as deleted on the vendor branch?
It seems that cvs just ignores them and doesn't update those files on
the branch.
What I'd lik
27 matches
Mail list logo
