[cvsnt] Re: Mergepoints

[Gerhard Fiedler]

Andrš Petr (EXT) wrote:

> After reading about branching and merging in "Open Source Development
> with CVS" book (and it look really scary) [...]

It looks scarier than it is. It requires care and diligence, though --
especially in the beginning. 

Independently of mergepoints, maybe you consider these hints, at least for
the first few attempts at branching and merging: 

- Always tag the codeline you are branching. This is basically the only
easy way to go back to the root of a branch. 
- Tag both branches before a merge. This makes sure that no matter what you
do, you always easily can go back to what you had before the merge. 
- Check out a few separate copies of the code, so that you have them
present in your sandbox: the tip of the branch you are merging into (this
one you obviously need in any case), the branch you are merging from (on a
tag, so that you can't commit there, for reference), the branch you are
merging into (on the tag you created in the step above, so that you can't
commit either -- as reference during the merge process), and possibly the
root of the branch (this may help you getting a quick overview what changed
on both branches since their separation).
- Get yourself a three-way visual diff application to compare the
directories and files of the various local copies you created in the step
above. Ideally it supports editing in place.
- Resist the temptation to fix any bugs you spot during merging that have
nothing to do with the merge process. Make a note of them, but leave them.
This help separating the merge changes from other code changes, and can
help analyse merge problems. This also ensures that a merge always changes
only one branch.
- Tag the branch into which you merged after the merge (that is, after the
commit that follows the merge). This helps later analyzing the merge
process if anything comes up that looks like a possible merge error.


Mergepoints are not an essentially new functionality, they are a
convenience. Instead of manually keeping track when the last merge occurred
and executing the appropriate two-point merge command, you rely on the
server keeping track of this and just tell it "merge in everything since
the last mergepoint". If you have a tag on the source branch at the last
mergepoint (and remember what tag that was :) you can achieve the same
result with the two-point merge.


> 2. Is it implemented on client or server or both? 

I think it needs to be supported by both. They are stored at the server,
but the client needs to be able to send the appropriate commands.

> [...] or is it possible to use other CVS clients (mainly those integrated
> in Java development environment like IntelliJ IDEA or BEA Weblogic
> Workshop 8.1) without degradation of functionality? 

I think no CVS client supports mergepoints. 

> [...] is usage of non CVSNT clients possible for users who will not
> perform merges (they will only implement changes and commit them)
> without any damage/loss of functionality of mergepoints and whole
> repository? 

I think that works, as long as they don't do any merges.


> 3. Here http://www.devguy.com/bb/viewtopic.php?p=1334 I found some
> interesting article about mergepoints, but it says that merges can
> happen only in one direction when using mergepoints. Can please somebody
> clarify it? 

Mergepoints mainly store the position on the source branch where the last
merge into the target branch happened. They don't change the merge process
itself. Merging in both directions is complicated, mergepoints or not. When
using mergepoints, you basically tell cvsnt: "merge in all changes on the
source branch since the last mergepoint and create a new mergepoint" --
just as you would tell cvs(nt) when doing two-point merges manually without
using mergepoints. While you can do that in both directions, the changes on
the target branch that you would merge back to the source branch will
include the merged-in code from the source branch, often modified to adapt
to other changes on the target branch, which is likely to create conflicts
when trying to merge back. 


> My idea is to create branch for these future features, merge changes from
> trunk to branch regularly and after release happens merge branch to
> trunk. (And probably create branch from release for fixes.) 

Many people do something similar. There has been a lengthy discussion here
recently about such scenarios and the problems with bi-directional merging.
Check out the thread "[cvsnt] Re: Branch merging - this seems wrong...". 

Basically, you merge your trunk regularly into your branch. At some point,
this branch development is complete. Now you merge in the trunk, and after
that, the branch contains all changes (now complete) from its own
development plus all changes from the trunk. At this point, you don't have
to merge this branch back to the trunk if you want it there, you just copy
it to the trunk. There are several methods given for this in the thread I
mentioned.

Gerhard