Re: Merge issue with deleted files

[Paul Sander]

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.

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.

On Nov 5, 2009, at 9:12 AM, Risman, Mark wrote:

> Cristian,
>
> By using the update command with the two "j" arguments, you'll "merge
> the differences between any two revisions into your working file."
> (source: http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_5.html#SEC62)
>
> The way I understand it, it's as if you were to look at the diff from
> revision <first "j" argument> to revision <second "j" argument>, and
> apply that to what's in your checkout. Kind of like how "cvs diff -e"
> will create a set of commands that can be applied to the first  
> revision
> to produce the second.
>
> In this case, the diff between those two revisions is "remove file".  
> So
> CVS applies a "remove file" to that file in your checkout. Would a
> conflict be more desired in this case?
>
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On Behalf Of
> Cristian
> Sent: Wednesday, November 04, 2009 2:16 PM
> To: address@hidden
> Subject: Merge issue with deleted files
>
> I have been using CVS for quite a while and started doing merges back
> about 4 years ago. Since, I have not run into any problems, till now
> that is. I would appreciate any help on this.
>
>
> Env: I am running CVS client and server 1.11.22 on Linux 2.6 Kernel.
>
>
> I have run into this issue when merging from one branch onto another.
> A file had been removed on branch B1 and modified on branch B2 with a
> couple of revisions (irrelevant perhaps, we were doing some
> refactoring).
>
> Branch B2 is my target branch - so I am merging B1 into B2.
>
> I have merged using two join commands so the common ancestor has been
> passed to cvs as the first -j. To my surprise, the file got removed
> from B2 branch by the merge, and was not flagged as a conflict - which
> I would have thought should happen in this scenario.
>
> # checked out B2
> cvs -q up -dP -jB1_ROOT -jB1 -kk
>
> Where B1_ROOT is rev 1.6 and B1 branch has been created off of
> B1_ROOT. I have 1.6.36.1 on B1 which is marked as 'dead' and 1.6.8.2
> in B2 -- we had two revisions on branch B2 since B1 was created at 1.6
> (B1_ROOT).
>
> When I noticed this, I have also tried using one -j essentially
> passing the branch name which also corresponds to the latest revision
> on the B2 branch. At the same time, in this particular case it would
> have also been alright I believe to use only 1 -j since it was the
> first merge from B1 to B2 so I would not have to worrry about merge
> history and the like.
>
> cvs -q up -dP -jB1 -kk
>
> There is a message been spit out by CVS 'file XX has been modified,
> but has been removed in revision B1 but the file is not been marked as
> a conflict, its status is 'up-to-date'. I am not sure what to do in
> the future about this because sometimes I do need to merge more than
> one time from a branch, in which case I would need to use two -j and I
> would run into the same issue.
>
>
> Thanks,
> Cristian
>
>
>
>
>
> **********************************************************
>
> MLB.com: Where Baseball is Always On