[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.
>
>