[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" <kerravon@nosppaam.w3.to> wrote in message
news:ROtGb.64619$aT.60772@news-server.bigpond.net.au...
> 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.
> >
> >
>
>