Re: Reimporting vendor projects where items have been deleted

[Laine Stump]

address@hidden (Larry Jones) writes:

> Laine Stump writes:
> > 
> > That's great, but your example doesn't use the tags normally suggested
> > in the results of imports, eg "-j NET:yesterday -j NET" (which in this
> > case wouldn't work anyway because it had been less than a day between
> > imports, but that's beside the point).
> 
> No, but it shows that the basic functionality does work.  If it didn't
> work for you, then either you're running an old version of CVS.

Nope. 1.11 server, straight from (post-1.11) CVS on client.

> or you did something wrong.

Unless the cvs import command is giving "wrong" instructions, I am not
doing anything "wrong". CVS is not performing as you described in your
original email message on the subject. Note the emphasized phrase
below:

address@hidden (Larry Jones) writes:
> Doing the merge that CVS suggests when there are conflicts (even if
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> there aren't any conflicts) will mark the appropriate files for
> deletion.  Committing the results of the merge will then delete them.

If you want to modify your statement to say "Doing a merge using the
tags placed on the branch at the time of the last two imports" (or
something similar), we'll be in complete agreement, but currently the
merge that cvs suggests does nothing of the sort, so either your
statement is incorrect, or there is a bug in cvs.

As for your example, it is *not* doing the merge that the cvs import
command suggests. It names specific tags (eg -j FIRST -j SECOND),
while the cvs import command recommends using two *branch* tags, the
first with a date offset specifier (eg -jNET:yesterday -jNET).

When I use specific tags as you did in your example, it does of course
work as you say (as I said in my last reply). However, when I use
branch tags as suggested by cvs import, no files are
deleted. Following is an example based on yours that demonstrates what
I'm talking about - note that 1) I used the merge command recommended
by cvs import when it found a conflict, and 2) nothing is marked for
deletion, as your message claimed would happen.

(One small deviation - I used "-jNET:'2 minutes ago'" rather than
"-jNET:yesterday" since it had been less than a day since the first
import. The results would be the same if I waited for another day and
then used "-jNET:yesterday" however. If you remain unconvinced, I can
do the same command over again with a one day wait in the middle ;-))


     # date; echo file1 >file1; echo file2 >file2; cvs import -m first tst NET 
FIRST
     Thu Mar 22 15:08:46 EST 2001
     N tst/file1
     N tst/file2

     No conflicts created by this import

# checkout a workspace and modify file2 to create a conflict on next import

     # cvs co tst
     U tst/file1
     U tst/file2
     # cd tst
     # echo more file2 >>file2
     # cvs commit -m"local commit"
     Checking in file2;
     /vol/cvsroot/tst/file2,v  <--  file2
     new revision: 1.2; previous revision: 1.1
     done
     # cd ..
     # rm -rf tst


# make some changes in dir to be imported - remove file1, modify file2
# so there will be a conflict, create file3

     # rm file1
     # echo more imported file2 >>file2
     # echo file3 >file3

     # date; cvs import -m second tst NET SECOND
     Thu Mar 22 15:11:27 EST 2001
     N tst/file3
     C tst/file2

     1 conflicts created by this import.
     Use the following command to help the merge:

===>         cvs checkout -jNET:yesterday -jNET tst


# Note that at this point, more than two minutes have passed since the
# first import, and less than two minutes since the 2nd (only a few
# seconds, actually). The fact that it gives us the change to file2
# from the vendor branch verifies that we have the timing correct.

# cvs suggested "-jNET:yesterday -jNET", but we know that it hasn't been
# a full day yet, so we use '2 minutes ago' as the time specifier.

===> # cvs co -jNET:'2 minutes ago' -jNET tst
     U tst/file1
     U tst/file2
     RCS file: /vol/cvsroot/tst/file2,v
     retrieving revision 1.1.1.1
     retrieving revision 1.1.1.2
     Merging differences between 1.1.1.1 and 1.1.1.2 into file2
     rcsmerge: warning: conflicts during merge
     U tst/file3

# (Note - no messages indicating files scheduled for deletion)