[cvsnt] Merging branch with identical versions still changes

Phil Richards news at derived-software.ltd.uk
Fri Nov 7 08:19:10 GMT 2003


On 2003-11-06, John Peacock <jpeacock at rowman.com> wrote:
>  Glen Starrett wrote:
> > When I'm about to merge in a branch back to MAIN, I first merge MAIN onto
> > the branch so that testing and conflict resolution happen on the branch, not
> > on MAIN.  Then when I merge the branch to MAIN it is seamless, shortening
> > the time my sandbox is being updated on MAIN.  
> Merging is _always_ performed against the local sandbox.  You
> shouldn't need to do this double hop unless you are trying to
> do the merge on a sandbox that is being used for something else
> (like a web site). [...]

Glen's approach (which happens to be the same as the one we use)
is extremely useful for certain types of development.

[Slightly off topic paragraph coming up...]

The problem with the "do everything on the branch and only worry
about mainline merging at the end" is that the merge can be 
non-trivial.  Especially if the branch has lived a bit too long.
We do *all* development on branches, and do test-driven development.
This means that we have a set of unit tests, and the mainline is
"guaranteed" to be in a state that passes them all.  To minimise
the amount of effort to merge branches to the mainline, we "lock"
the mainline when we do it - for *this* to work, it makes sense
to merge the mainline to the branch as the last stage of the process,
get everything working, and *then* do the merge to mainline.
(That way, if the merge is harder than expected, we can "unlock"
the mainline, sort the problems, and start the process again - and
mergepoints *really* make this easy to do.  We find that we
do lots of mainline-to-branch merges now-a-dats because it *is*
so easy.)

> As for why your method causes every file to be marked as modified,
> without your actual commands (so it can be reproduced) anything I
> say is speculative. [...]

[back on topic again]

:-)  The sequence is (for a single file):
1. branch the mainline
2. on the mainline commit a new version of the file
3. on the branch, merge the changes from the mainline, and commit
4. merge the branch to the mainline

At this point, the mainline will indicate that the file is
changed, but diff will show no differences.  A simple "cvs update"
on the file (which would normal reset such a problem) won't
do anything - the mergepoint information itself is viewed as a
"change" that needs commiting, even though the delta would be null.

It all makes sense, and CVSNT is doing the right thing.  It is
important to be able to commit a null-delta because the result
of the merge *might not* have been the same - and then the 
developer looks at the conflict and decides the mainline version
is the one that should be kept so winds back the conflicts.  This
ends up with a file that is no different to the "BASE" version
but *is the result of a merge*.

The patch Tony was talking about makes the server identify at
the point *it* does the merge that there are no differences
and then doesn't send back any changes.  Result: no mergepoint
recorded, and no change to the file.

The problem is... well, it is a quite tricky area that is being
played around with and it although I'm pretty darned sure it
works properly, I wouldn't like to bet my archive on it *just*
at the moment...  (It passes all my tests, but my tests aren't
exhaustive.)

phil
-- 
change name before "@" to "phil" for email



More information about the cvsnt mailing list