RE: Reimporting vendor projects where items have been deleted

[Nathan Herring]

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
heuristic:

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
  AND that branch has the same version as the branch version specified
on import
  AND the most recent revision on the vendor-tag branch is not marked
dead,
THEN
  create a new version on the vendor-tag branch marked as dead
END IF

NOTE: You don't touch files in this case that are missing the original
vendor-tag branch tag, as they were never part of a previous import for
this vendor (at least as far as you specified).

NOTE: If you remove the original vendor-tag from the file, it will no
longer assume you've imported it, and if you reimport using this
feature, it will not mark it dead, as the heuristic no longer has any
way to determine that it was part of a previous import (for this
vendor). However, I doubt many people are going to do this accidentally
or have some strange reason to do this.

Now, it may be that the current code (which I have not inspected) only
looks through the import list and makes changes to the repository. In
that case, you'd have to have a second iteration that looks through the
repository list and matches it up against the import list, and in the
case of missing files, checking to see whether it (1) had the vendor
branch 

Here is your example altered as I would see it with the above new
functionality. I'm using -D as the special new option for this feature.
I'm using 'R' as the code for I've removed this file from the
repository.:

        $ echo file1 >file1
        $ echo file2 >file2
        $ cvs import -m first tst NET FIRST
        N tst/file1
        N tst/file2

        No conflicts created by this import

        $ rm file1
        $ echo file3 >file3
        $ cvs import -D -m second tst NET SECOND
        N tst/file3
        R tst/file1
        U tst/file2
        
        No conflicts created by this import
        
Now, file1 would have revisions 1.1 (alive), 1.1.1.1 (alive), and
1.1.1.2 (dead).

Furthermore, if you were to check out tst to either NET or SECOND, you'd
get exactly what you wanted.

nh

P.S. Here's a second example:

        $ mkdir vendor1
        $ cd vendor1
        $ echo 1>vendor1_file1
        $ echo 2>vendor1_file2
        $ cvs import -m first tst vendor1 vendor1_v1
        N tst/vendor1_file1
        N tst/vendor1_file2

        No conflicts created by this import

        $ mkdir ../vendor2
        $ cd ../vendor2
        $ echo 1>vendor2_file1
        $ cvs import -m second tst vendor2 vendor2_v1
        N tst/vendor2_file1

        $ cd ../vendor1
        $ rm vendor1_file1
        $ cvs import -D -m third tst vendor1 vendor1_v2
        R tst/vendor1_file1
        U tst/vendor1_file2

        No conflicts created by this import

NOTE: It didn't remove vendor2_file2, because, depsite the fact that the
import file did not exist, the repository file did not have the original
vendor1 tag, and so CVS assumes it wasn't part of this vendor's import
and leaves it alone.

-----Original Message-----
From: Larry Jones [mailto:address@hidden
Sent: Thursday, March 22, 2001 8:59 PM
To: Eric Siegerman
Cc: address@hidden
Subject: Re: Reimporting vendor projects where items have been deleted


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

_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs