Hi,
Matthew D. Fuller wrote:
> I would say that a far greater contributor in practice would simply be
> frequency. If you diverge on your significant feature for 6 months,
> then try to merge in upstream changes from the main dev, you will be
> in hell no matter what merge algorithm you use.
Do you have experience with automatic merging tools, to back up this
assertion. If so I'd be curious to know.
I'm maintaining the Postgres-R branch since about late PostgreSQL 7.4
using monotone's cvs_import and propagating from the original PostgreSQL
repository to my Postgres-R branch. And even if I propagate quite
rarely, automatic merge tools (i.e. monotone) helped me a *great
deal(tm)*. (What's still awkward, is the lacking cvs_import.)
> If you merge in
> upstream changes every few days, however, you will have many fewer and
> much simplier conflicts to deal with.
A VCS as good as monotone gives you the option to merge random revisions
in between. Thus, if you didn't merge for six months, you can easily do
incremental merges and i.e. do six times a merge of one month worth of
mainline code.
Of course, that still seems like more work, than if you do it frequently
:-) But the VCS should give you the option and let *you* choose,
instead of enforcing whatever it thinks should be good for you.
> A VCS that makes frequent merges easy results in easier conflict
> handling, not by some magical auto-resolution, but just by letting you
> do it in ongoing regular and small bites.
I disagree, by experience. And please note, that it's not magic, but (in
case of monotone) a provably correct (and simple to understand, I might
add) algorithm which merges cleanly whenever possible.
Regards
Markus
