bug-cvs
[Top][All Lists]
Advanced

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

Problem with cvs 1.11.2 and tracking third-party sources


From: Stefan Scherer
Subject: Problem with cvs 1.11.2 and tracking third-party sources
Date: Thu, 24 Oct 2002 15:32:23 +0200

Hi,

I have a strange problem tracking third-party sources with CVS.
It seems to be a bug in cvs. I have used cvs 1.11.2 for these tests.

We have a source tree from a software vendor in a vendor
branch "GS". We also have modified some of these source codes
in the main branch.

After our last software update from our vendor we have
noticed that some of our changes have gone.

I will explain what we have done so you can have a look
what is going wrong in cvs.



I have extracted one of the files to give you the history
files before and after the cvs import. See the attached tarfile.

The vendor branch is named "GS", the previous import 
of vendor source codes has been tagged with "GS_7_03".
You can find this revision file in the tarfile as "before-import.ps,v".


The file gs_setpd.ps was modified some time ago by us in the following
way:

prompt> cvs diff -rGS gs_setpd.ps 
Index: gs_setpd.ps
===================================================================
RCS file: /home/u1/plscvs/test/gs_setpd.ps,v
retrieving revision 1.1.1.7
retrieving revision 1.4
diff -r1.1.1.7 -r1.4
717a718,726
> 
> % SEPP PATCH
> % 11.07.2000, ss: execute optional string after setting new page
>   systemdict /SetPageDevicePatch known
>   {
>   systemdict /SetPageDevicePatch get cvx exec
>   } if
> % SEPP PATCH
> 

So, we only have added some lines of code into it. These
changes have been made before the GS_7_03 import.



After receiving the new software version 7.31, I have 
imported the source codes with the following command:

prompt> cvs import -ko -m "GS 7.31" test GS GS_7_31
C test/gs_setpd.ps

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

        cvs checkout -j<prev_rel_tag> -jGS_7_31 test


Our previous vendor release was imported with tag GS_7_03,
so I used this command (I also retried it with
-jGS:yesterday -jGS but it had the same effect):

prompt> cvs checkout -jGS_7_03 -jGS_7_31 test
cvs checkout: Updating test
U test/gs_setpd.ps
cvs checkout: nonmergeable file needs merge
cvs checkout: revision 1.1.1.8 from repository is now in test/gs_setpd.ps
cvs checkout: file from working directory is now in .#gs_setpd.ps.1.4
C test/gs_setpd.ps


The strange thing is, cvs showed me a "C" state, but looking with
cvs -n -q update to the source tree, the file has only "M" state
and can be commited.

That's what I always do. This examples shows only one file,
the normal source tree has some hundred files and you can't have
a look to all lines in the stdout. I always check only afterwards
with cvs -n -q update and work through all files with a "C" state.

Ok, I've commited the merge results and now our changes have
gone in the main branch. The following diff shows no differences
between main branch and vendor branch.

prompt> cvs diff -rGS gs_setpd.ps
Index: gs_setpd.ps
===================================================================
RCS file: /home/u1/plscvs/test/gs_setpd.ps,v
retrieving revision 1.1.1.8
retrieving revision 1.5
diff -r1.1.1.8 -r1.5


In the attached tarfile you can find the revision file before
the import ("before-import.ps,v"), after the import ("after-import.ps,v")
and after the commit to the main branch ("gs_setpd.ps,v").

Please have a look at this, because I can't see any
difference to previous cvs import/checkout cycles when
everything worked fine.

Best Regards,

Stefan




-- 
Stefan Scherer
SEAL Systems          Tel.  : +49 (0) 9195-926-128
Lohmuehlweg 4         Fax   : +49 (0) 9195-1739
D-91341 Roettenbach   MailTo:address@hidden
Germany               WWW   : http://www.sealsystems.de

Attachment: cvs-import-bug.tar.gz
Description: GNU Zip compressed data


reply via email to

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