info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Reimporting vendor projects where items have been deleted


From: Nathan Herring
Subject: RE: Reimporting vendor projects where items have been deleted
Date: Fri, 23 Mar 2001 12:53:25 -0800

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 "live" file.

I'm not sure I necessarily agree with this. For most purposes, a file
missing a static tag is equivalent to a file containing a static tag to
a dead revision. Mostly, it would just take up room on the server. If
you can think of a real reason to have this, let me know.

>But perhaps that's what Nathan meant by:
>>   AND that branch has the same version as the branch version
specified
>> on import
>
>in which case, all I'm questioning is whether the following
>condition should go away:
>>   AND repository file has a branch with the same name as the
vendor-tag
>> argument

I ended up sending the e-mail in a half revised state accidentally, so I
didn't end up explaining why we need this. 

First, thanks for pointing out my errors!

Here are two cases we wish to get right:

CASE 1: Vendors using different vendor branches (not just names).
        $ echo 1>vendor1
        $ cvs import -m vendor1_version1 tst vendor1 vendor1_version1
        N tst/vendor1

        No conflicts created by this import

        $ rm vendor1
        $ echo 2>vendor2
        $ cvs import -m vendor2_version1 -b 1.1.3 tst vendor2
vendor2_version1
        N tst/vendor2

        No conflicts created by this import

        $ rm vendor2
        $ cvs import -D -m vendor1_version2 tst vendor1 vendor1_version2
        R tst/vendor1

        No conflicts created by this import

This deletes file vendor1 because a file exists on the vendor branch
we're importing to (1.1.1), and doesn't exist in the import list. This
doesn't delete file vendor2 because it doesn't contain the branch 1.1.1.

CASE 2: Vendors using different names, but same vendor branches.
        $ echo 1>vendor1
        $ cvs import -m vendor1_version1 tst vendor1 vendor1_version1
        N tst/vendor1

        No conflicts created by this import

        $ rm vendor1
        $ echo 2>vendor2
        $ cvs import -m vendor2_version1 tst vendor2 vendor2_version1
        N tst/vendor2

        No conflicts created by this import

NOTE: at this point vendor1 == vendor2 == 1.1.1

        $ rm vendor2
        $ cvs import -D -m vendor1_version2 tst vendor1 vendor1_version2
        R tst/vendor1

        No conflicts created by this import

With the heuristic I described, this would also do the "right" thing,
since it checks the name of the vendor branch as well as the branch
version number. You don't want to delete the vendor2 files, and the only
way to make sure it's not a vendor1 file is to make sure it doesn't have
the vendor1 branch tag.

This is somewhat important, as most people don't generally realise that
if they specify a different vendor name, they won't get a different
vendor branch, but rather they'll be on the same vendor branch with the
new tag assigned.

You can end up royally screwed if you have different vendors with the
same file that you import into the same location, failing to specify
different branch versions, and then use the delete feature on a
subsequent import where the file doesn't exist. However, this is
certainly an extreme case, and not the normal.

nh



reply via email to

[Prev in Thread] Current Thread [Next in Thread]