[Top][All Lists]
[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
- RE: Reimporting vendor projects where items have been deleted, (continued)
- RE: Reimporting vendor projects where items have been deleted, Nathan Herring, 2001/03/20
- Re: Reimporting vendor projects where items have been deleted, Stephen Rasku, 2001/03/20
- RE: Reimporting vendor projects where items have been deleted, Jerry Nairn, 2001/03/22
- RE: Reimporting vendor projects where items have been deleted, Nathan Herring, 2001/03/23
- Re: Reimporting vendor projects where items have been deleted, Eric Siegerman, 2001/03/23
- Re: Reimporting vendor projects where items have been deleted, Derek R. Price, 2001/03/23
RE: Reimporting vendor projects where items have been deleted,
Nathan Herring <=