bug-cvs
[Top][All Lists]
Advanced

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

Re: cvs 1.11.10 fails to detect deletion conflict


From: Paul Edwards
Subject: Re: cvs 1.11.10 fails to detect deletion conflict
Date: Thu, 25 Dec 2003 04:36:01 GMT

n the head version (1.225) of update.c, on around line 2217, we
have the code shown below.

I have the following questions:

1. why is it using join_rev2 instead of jrev2?

2. Why is there not a check for IS_DEAD as well?

3. Why is any of this necessary at all, can't we delete
the "join_rev2 == NULL", don't we already know that it
is NULL?

4. Maybe we actually know that rev2 is NULL, should
we be using that instead?

Regardless, deleting "join_rev2 == NULL" fixes my
test case.

BFN.  Paul.


 /* If only one join tag was specified, and the user file has
           been changed since the greatest common ancestor (rev1),
           then there is a conflict we can not resolve.  See above for
           the rationale.  */
 if (join_rev2 == NULL
     && strcmp (rev1, vers->vn_user) != 0)
 {
     if (jdate2 != NULL)
  error (0, 0,
         "file %s has been modified, but has been removed in revision %s as of 
%s",
         finfo->fullname, jrev2, jdate2);
     else
  error (0, 0,
         "file %s has been modified, but has been removed in revision %s",
         finfo->fullname, jrev2);

     /* FIXME: Should we arrange to return a non-zero exit
               status?  */

     if (rev1 != NULL)
  free (rev1);

     return;
 }

"Paul Edwards" <kerravon@nosppaam.w3.to> wrote in message 
news:5b5Cb.48795$aT.10023@news-server.bigpond.net.au...
> "Jim.Hyslop" <Jim.Hyslop@Leitch.com> wrote in message 
> news:mailman.1577.1071158672.399.bug-cvs@gnu.org...
> > Paul Edwards [mailto:kerravon@nosppaam.w3.to] wrote:
> > > I came extremely close to getting my fingers burnt again
> > > today.  The problem is that if we have a base, and one
> > > person has modified the file, but the other person has
> > > deleted that same file, when I come to do a merge, one
> > > way CVS detects, the other way it is silent.
> > This description does not match the sequence of steps you outlined below,
> > but in any case...
> >
> > > # This script demonstrates a problem with CVS 1.11.10 when
> > > # a file is deleted.  No conflict or warning is produced.
> > [...]
> > > cd base
> > > cvs import -b 1.1.101 -ko -m "base import" tempmerge base base-1
> > >
> > > cd ../pvcs
> > > cvs import -b 1.1.201 -ko -m "pvcs import" tempmerge pvcs pvcs-1
> > It seems the lack of error message was recently introduced. At this point,
> > using 1.11.5, I got an error message:
> >
> > jhyslop@ashiko:$ cvs import -b 1.1.201 -ko -m "pvcs import" tempmerge pvcs
> > pvcs
> > -1
> > C tempmerge/file.txt
> >
> > 1 conflicts created by this import.
> > Use the following command to help the merge:
> >
> >         cvs checkout -j<prev_rel_tag> -jpvcs-1 tempmerge
> >
>
> I'm sorry, should have explained better.
>
> If you take a look at "conflicts.txt" you can see where I
> expected a warning.  There is no warning, just a
> "scheduled for deletion".
>
> The conflicts on the import are innocuous setup messages.
>
> BFN.  Paul.
>
>




reply via email to

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