[cvsnt] But... (was: No conflict when merging, where one isexpected)

Mike Lehmann meiklehmann at gmx.de
Wed Sep 3 18:15:22 BST 2003


A more simple example, we have tested:

- FileA has a branch "release-1_0-branch"
- development goes on and due refactoring FileA is renamed to FileB (or 
moved to somewhere else in the project)
- now a bug is reported for version 1.0 and it needs to be fixed in 
release-1_0-branch
- trying to merge the changes back to the main trunk looses the made 
changes
- CVS must recreate FileA in the maintrunk and mark it as conflict, 
otherwise the changes are lost!!!
   => then we can merge the changes manually to FileB

--Mike


On Wed, 3 Sep 2003 10:02:50 -0700, Glen Starrett <grstarrett at cox.net> 
wrote:

>> Well, deleting the file is nearly the same as removing all
>> lines from it.
>
> My $0.02....  Looking at this from a more code-oriented view, let's walk
> through more specific examples.
>
> For all example, assume File A is sourcecode that uses File B.  Perhaps
> Dev 1 edited File A and removed all use of File B, then deleted File B
> to be tidy.  This was done on MAIN.
>
> ** I haven't tested these, but I believe it works this way **
>
>
> Example 1
> ==========
> Now along comes Dev 2 on their own branch.  They modify File A to use a
> new function in B and change B to add that new function.
>
> Merge Dev 2's branch into HEAD, and you WANT File B to be there, since
> it is dependent.
>
> How would CVS know to remove B?  It was changed, it needs to be merged
> in, it is part of the valid sandbox on the branch that you want brought
> into the MAIN.
>
>
> Example 2
> ==========
> Dev 2 on a branch edits some files, but NOT B.  Since B didn't change
> from the merge point, it is not merged into the sandbox and is not
> re-added to the HEAD.
>
>
> Example 3 (possible solution)
> ==============================
> Dev 2 is on a branch and makes some changes to any files out there.
> They know they must merge their changes onto MAIN.
>
> They perform the merge on their branch, by merging HEAD to their sandbox
> FIRST.  The irrelevant File B is removed from the branch at that point.
>
> Now, when the dev merges to HEAD, File B stays away and everyone is
> happy.  I think.
>
>
> Is this correct?  Would example 3 work the way you want it to?  With
> cvsnt's mergepoint processing making this easy I've been doing that
> scenario here and it seems to work very nicely, although I haven't tried
> it yet with file removal.
>
> Regards,
>
> Glen Starrett
>
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/


More information about the cvsnt mailing list