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: Eric Siegerman
Subject: Re: Reimporting vendor projects where items have been deleted
Date: Fri, 23 Mar 2001 15:12:54 -0500
User-agent: Mutt/1.2.5i

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

What he said!

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.


> 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_file1 [NB: this actually said "vendor2_file2";
> I've corrected what I assume was a typo  -ES ], 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.

This is the only part I question -- and I do mean "question"; I'm
not asserting that it's wrong, but wondering whether it might be,
and asking people to think about it.

Should this be based on the import branch number, rather than
name?  That is: if, in the above example, branch-tags "vendor1"
and "vendor2" both referred to branch 1.1.1, then they'd be
considered identical for this purpose; vendor2_file1 *would* be
deleted during the "third" import.  But if "vendor1" and
"vendor2" referred to different branches, eg. the vendor2 import
had been:
        $ cvs import -m second -b 1.1.3 tst vendor2 vendor2_v1
then, as Nathan says, vendor2_file1 would *not* be deleted during
the "third" import -- indeed, in this specific case, it wouldn't
have to be deleted, since it wouldn't be on branch 1.1.1 in the
first place.

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

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)



reply via email to

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