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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
