Re: Merge issue with deleted files

[Cristian]

Thanks for your response Paul.

> Christian describes a merge conflict:  new revisions were created on  
> one branch, and the file was deleted on the other.  This is definitely  
> a conflict because the new revisions might contain critical data  
> (though Christian says that in this particular case they are not).  
> CVS should present the user with a method of resolving the conflict by  
> asking the user whether or not to delete the file on the target  
> branch, and if the user declines deletion then CVS should treat the  
> conflict as an ordinary merge conflict in which the file deletion is  
> replaced by an empty file, letting the user edit the resulting file.

A conflict would have been my expectation in this particular case.
There was actually a big fuss about this in our group because we ended
up going to QA and a bunch of bugs were found until this was tracked
down. What happened is that a group of developers have worked on a
branch doing some refactoring which involved moving some stuff around
(took them almost 4 months) while the rest of the developers were
working on the 'regular' development branch totally unaware of what is
going on with regards to the refactoring. The idea was that when we
had everything merged back in they would get all of these changes done
in the development branch for which the directories/files have moved,
as conflicts, side by side with all of the other expected conflicts
that we get when we merge. At the time of the merge, I did not have
much in the way of details about the kind of work that was done.


As I mentioned before, what gets me is the different behaviour of CVS
with regards to using one -j vs two -j's.

For one -j, the file that underwent changes in the development branch
does not change status (up-to-date) but a message is given.
For two -j's the file that underwent changes in the development branch
gets removed, marked as "R" and no message is given.

Even if I was to use the one -j, with only a message given I don't
know how I could have found it. When I merge, at the size of our
product, on a medium size merge I probably get over 20.000 lines of
output - so unless I know to specifically look for this message, I
would completelly missed what is happening and instead of the files
been removed, I would have ended up with files that are no longer in
play.

For the two -j's, stil shaking my head.

I would really think that a conflict would be the way to go. I can
understand some would say that technically this is not a conflict. No
problem, then perhaps a different state? Anything that one can query
the workspace and be able to appropriatelly deal with this situation.
But I believe a different state is not that easy to implement.

> Now the hard part:  Suppose the deletion was declined and the result  
> of the above merge is then merged back to the contributing branch.  
> Does CVS leave the file in its deleted state?  Or does CVS resurrect  
> the file and keep the result of the prior merge?  This time there is  
> no conflict, but there's also a good chance of getting incomplete  
> results requiring unusual manual intervention.
>

I would think that if the deletion is declined, then CVS should keep
the result prior to the merge. That would make sense to me, but I
might be missing something.


Thanks,
Cristian