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.



---------------------------(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

Reply via email to