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: Sun, 28 Dec 2003 06:44:13 GMT

Actually, I think what is required is something like:

>  if (join_rev2 == NULL
>      && strcmp (rev1, vers->vn_user) != 0)

if (strcmp(rev1, vers->vn_user) != 0)
     && there is a genuine change (ie not empty) between rev1 and vn_user)

then we have a conflict.

And it doesn't just apply to the restricted case where no 2nd
join was provided.  I don't see any reason to put in that
condition.

So I assume a call to RCS_cmp_file is in order?  I have
done this and tested both the situation where it shouldn't
detect a conflict and the situation where it should.  I'll
send the patch and the two test cases I used.

BFN.  Paul.


"Paul Edwards" <address@hidden> wrote in message news:address@hidden
> 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" <address@hidden> wrote in message news:address@hidden
> > "Jim.Hyslop" <address@hidden> wrote in message news:address@hidden
> > > Paul Edwards [mailto:address@hidden 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:
> > >
> > > address@hidden:$ 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]