Re: Reimporting vendor projects where items have been deleted

[Eric Siegerman]

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't.

I defer to your (much) greater knowledge of CVS internals.  I
suggested this *because* it's what happens with unchanged live
files, and it seems cleaner to me to treat unchanged files
(whether live or dead) in the same way, unless there are reasons
to do otherwise -- "make sure special cases really are special"
and all that.  I'll take your word for it that there are indeed
reasons to treat these cases differently.


>
> > Should this be based on the import branch number, rather than
> > name?
>
> Absolutely not.  If the same vendor branch name was used in both cases then 
> it should
> already be an error if they point at different branches.

Do you mean where someone does this?
        cvs import          foo vendor1 release1
        cvs import -b 1.1.3 foo vendor1 release2
                                      ^
                                    [sic]

I wasn't trying to address this case, which is clearly an error,
but rather Nathan's Case 2 below.  I guess I was unclear.  Sorry.


On Fri, Mar 23, 2001 at 12:53:25PM -0800, Nathan Herring wrote:
> CASE 1: Vendors using different vendor branches (not just names).
>         [importing on vendor branch A does *not* check "dead"
>         revisions into vendor branch B]

No argument here!


> CASE 2: Vendors using different names, but same vendor branches.
To summarize:
        cvs import foo vendor1 release1
        cvs import foo vendor2 release2
with no -b option either time.

After looking into this more closely, it seems each of us is
right some of the time :-)

Under Nathan's assumption -- that this happened because a user
was trying to create a second vendor branch but forgot the -b --
he's right; his proposed behaviour works better.

But there's another way this situation can arise (which is the
one I was thinking of when I proposed my change): if the user was
trying to import a new release into an existing vendor branch,
but mistyped the tag name.  I'll call this "case 3", even though
it's isomorphic to case 2.

In case 3, my proposed behaviour works better -- if a file is in
release1 but not in release2, the user does *not* want it to
appear on what they intended to be the *only* vendor branch.
Thus, it shouldn't appear on either actual branch, and my way, it
doesn't.

But note:
  - Cases 2 and 3 are both due to user error
  - Both of them have other problems, which keep them from doing
    what the user wanted (as opposed to what they mistakenly
    asked for :-)

Thus, it doesn't seem to matter much which way this particular
decision goes; it comes down to arguing over which error users
are more likely to make.

Unless, of course, there are more *non-error* cases; if there
are, what's right for those should win over both cases 2 and 3.

--

|  | /\
|-_|/  >   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)