Re: Major change in conflict handling between 1.12.9 and 1.12.13?

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Stephanie,

> Date: Fri, 02 Jun 2006 12:34:06 +0200
> From: Stephanie Seibt <stephanie.seibt@hacon.de>
> User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
> To: "Mark D. Baushke" <mdb@gnu.org>
> Subject: Re: Major change in conflict handling between 1.12.9 and 1.12.13?
> X-SBScore: 0 (Spam Threshold: 20) (Block Threshold: 5)
> 
> Hi Mark,
> 
> thanks for your efforts.
> On my windows system I'm not able to patch my clients, the compilation
> of the sources didn't work ;-(
> I only have binaries.

I understand. FWIW binary/feature/x86-woe/cvs-1-12-13a.zip has been
uploaded to the area on http://download.savannah.gnu.org/releases/cvs/

which has a separate important windows client fix.

> Now I've tested with the same file as before on an actual gentoo-linux.

Ahhh... now, on gentoo-linux I KNOW you can fetch a copy of the
cvs-1.12.13 sources and apply the patch of my last e-mail to see if it
helps you or not.

> 
> Environment like before: Debian server cvs-1.12.9 (Debian-patch) with
> pserver access.
> 
> Steps 1) to 4) with client cvs-1.12.12 on the gentoo machine
> 
> The content of the Entries file is the same as before and persists at
> different cvs -n update calls.
> I've tried the updates after my join with three clients:
> cvs-1.11.20 and cvs-1.12.12 shows the conflict, cvs-1.12.13 does not.
> 
> Unfortunately I'm not able to send the file,v to you, because it's not
> my private software.

You may wish to try using the CVS_CLIENT_LOG environment variable as Jim
suggested. However, it might expose parts of your file, so please do
look at the ${CVS_CLIENT_LOG}.in and ${CVS_CLIENT_LOG}.out files closely
before you just send them along to us.

I am also interested to know the offset in bytes of the conflict markers
into the file.

I am expecting that the ${CVS_CLIENT_LOG}.in file will contain lines
like this:

Entry /file/1.5/+=//
Unchanged file1
update

And that the ${CVS_CLIENT_LOG}.out file will contain lines like this:

first-dir/
MT text C 
MT fname file
MT newline
error  

if everything is working correctly. The "+=" information in the date
field is VERY important.

        -- Mark

> 
> Cheers, Stephanie
> 
> 
> Mark D. Baushke schrieb:
> > Hi Stephanie,
> > The information you are producing for me is not very helpful. :-(
> > I have moved this discussion to the bug-cvs mailing list. For folks
> > just
> > joining this problem, look on the info-cvs@gnu.org list archives.
> > Grasping at straws, the only change I see that might remotely have
> > caused a change in behavior between cvs 1.12.9 and 1.12.13 is this one:
> > 2005-09-22  Derek Price  <derek@ximbiot.com>
> >     * classify.c (Classify_File): Consolidate redundant
> > conditionals.
> > Does the patch below fix your problem? (Sadly, this means you will
> > need
> > to (re)build CVS. If you are not able to build from the cvs 1.12.13a
> > sources, this puts us in a bit of an impass as I have no windows boxes
> > of any kind in my world...) If you are able to reproduce the problem on
> > a Debian system, then things might be easier for you to track down.
> >     -- Mark
> > --- cvs-1.12.13/src/classify.c.orig 2005-09-22 20:37:42.000000000
> > -0700
> > +++ cvs-1.12.13/src/classify.c      2006-06-02 02:05:02.103376910 -0700
> > @@ -236,8 +236,19 @@ Classify_File (struct file_info *finfo,
> > finfo->fullname);
> >             ret = T_REMOVE_ENTRY;
> >         }
> > -       else if (strcmp (vers->ts_user, vers->ts_rcs)
> > -                && No_Difference (finfo, vers))
> > +       else if (strcmp (vers->ts_user, vers->ts_rcs) == 0)
> > +       {
> > +
> > +           /*
> > +            * The user file is still unmodified, so just remove it from
> > +            * the entry list
> > +            */
> > +           if (!really_quiet)
> > +               error (0, 0, "`%s' is no longer in the repository",
> > +                      finfo->fullname);
> > +           ret = T_REMOVE_ENTRY;
> > +       }
> > +       else if (No_Difference (finfo, vers))
> >         {
> >             /* they are different -> conflict */
> >             if (!really_quiet)
> > @@ -249,13 +260,10 @@ Classify_File (struct file_info *finfo,
> > }
> >         else
> >         {
> > -
> > -           /*
> > -            * The user file is still unmodified, so just remove it from
> > -            * the entry list
> > -            */
> > +           /* they weren't really different */
> >             if (!really_quiet)
> > -               error (0, 0, "`%s' is no longer in the repository",
> > +               error (0, 0,
> > +                      "warning: `%s' is not (any longer) pertinent",
> >                        finfo->fullname);
> >             ret = T_REMOVE_ENTRY;
> >         }
> > @@ -284,9 +292,7 @@ Classify_File (struct file_info *finfo,
> > error (0, 0, "warning: `%s' was lost", finfo->fullname);
> >             ret = T_CHECKOUT;
> >         }
> > -       else if (!strcmp (vers->ts_user,
> > -                         vers->ts_conflict
> > -                         ? vers->ts_conflict : vers->ts_rcs))
> > +       else if (strcmp (vers->ts_user, vers->ts_rcs) == 0)
> >         {
> >             /*
> > @@ -300,8 +306,6 @@ Classify_File (struct file_info *finfo,
> > if (vers->entdata->options &&
> >                 strcmp (vers->entdata->options, vers->options) != 0)
> >                 ret = T_CHECKOUT;
> > -           else if (vers->ts_conflict)
> > -               ret = T_CONFLICT;
> >             else
> >             {
> >                 sticky_ck (finfo, aflag, vers);
> >   ------- original message -------
> > Date: Fri, 02 Jun 2006 10:44:55 +0200
> > From: Stephanie Seibt <stephanie.seibt@hacon.de>
> > To: "Mark D. Baushke" <mdb@gnu.org>
> > Cc: info-cvs@gnu.org
> > Subject: Re: Major change in conflict handling between 1.12.9 and 1.12.13?
> > Hi Mark,
> > Mark D. Baushke schrieb:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >> Stephanie Seibt <stephanie.seibt@hacon.de> writes:
> >>
> >>> here is my test case:
> >>>
> >>> 1) cvs update -j last_join_tag -j BRANCHNAME >logfile 2>&1
> >>> 2) content of logfile:
> >>>    RCS file: /cvs-repository/path_to_file/file,v
> >>>    retrieving revision 1.2
> >>>    retrieving revision 1.2.10.1
> >>>    Merging differences between 1.2 and 1.2.10.1 into file
> >>>    rcsmerge: warning: conflicts during merge
> >> As I do not actually have your file,v available as a test case, this
> >> does not help very much.
> >>
> > file revision 1.2
> > snip:
> >       my @r = (q$Revision: 1.2 $ =~ /\d+/g);
> > file revision 1.2.10
> > snip:
> >       my @r = (q$Revision: 1.2.10.1 $ =~ /\d+/g);
> > file after join:
> > <<<<<<< file
> >       my @r = (q$Revision: 1.5 $ =~ /\d+/g);
> > =======
> >       my @r = (q$Revision: 1.2.10.1 $ =~ /\d+/g);
> >>>>>>>> 1.2.10.1
> >
> >>> 3) content of CVS/Entries:
> >>>    /file/1.5/Result of merge+Fri Jun  2 08:02:40 2006//
> >>> 4) cvs -n update file shows nothing (is cvs-1.12.13 for Windows)
> >> And is the contents of the CVS/Entries file unchanged after this
> >> step #4 operation?
> >>
> > the content is unchanged
> >
> >>> 5) cvs-1.11.17 -n update shows (also Windows client)
> >>>    C file
> >> What dose 'cvs-1.12.13 version' output? (i.e., what is the the server
> >> revision of CVS)? It would also be good to know the server hardware and
> >> operating system type and any special configurations that went into the
> >> server versio n of cvs.
> >> Are you able to give me any further details about the configuration
> >> of
> >> the cvs 1.12.13 you are using?
> >>
> > I thought I did it in my first mail
> > Environment: remote server cvs-1.12.9 (Debian-patch, should be equal
> > to cvs-1.12.13)
> > pserver access
> > client cvs-1.12.13 for Windows (downloaded from gnu.org)
> > output of cvs-1.12.13 version is
> > Client: Concurrent Versions System (CVS) 1.12.13 (client)
> > Server: Concurrent Versions System (CVS) 1.12.9 (client/server)
> > the server is Debian GNU/Linux 3.1
> >
> >>> Hope this helps, Stephanie
> >> Sadly, not yet. Until an unless I can understand what is happening,
> >> I am
> >> not able to fix it.
> >>    -- Mark
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.3 (FreeBSD)
> >> iD8DBQFEf/UMCg7APGsDnFERAt6zAJ46fX+Jqrrpkz/iyeUHBCVp5LjCigCffM8q
> >> IqPCv3BFVDlTQD1tIXwxIhQ=
> >> =Tkhg
> >> -----END PGP SIGNATURE-----
> >>
> > Greetings, Stephanie
> >
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)

iD8DBQFEgGFsCg7APGsDnFERApeRAKCJ6lafWmyzfH2qOdgD/oe+63i86gCgzB5e
bPKOEi2KnmZXpQ9HQ/e+PIU=
=ezWc
-----END PGP SIGNATURE-----