Chris Angelico <ros...@gmail.com>: > On Sat, Jan 2, 2016 at 8:48 PM, Marko Rauhamaa <ma...@pacujo.net> wrote: >> Having struggled with Perforce, SVN and CVS, I was hopeful Mercurial >> would be everything Teamware was. >> >> Unfortunately, it wasn't. The big disappointment was the treatment of >> a repository as the atomic unit. > > You'll need to elaborate on this. Is a repository too large or too > small as an atomic unit?
If a repository contains independent changes, Hg and Git fail to understand that the changes could be independent and force you to resolve a merge conflict where no real conflict exists. The whole philosophy of dependent and independent changes is complicated; only Darcs has attempted to address the issue scientifically (<URL: http://darcs.net/Theory/GaneshPatchAlgebra>). However, Teamware chose an opportune approximation by treating each file's version history independently. Teamware's approach works nicely for backporting. You often fix a bug in the development version and would like to propagate the fix to an older version (= branch/stream/fork) of the product. In Teamware, the propagation would not generate a conflict so it doesn't need to be resolved. No special cherrypicking is involved, and afterwards, you can't tell if the change was made first to the old version/branch/stream/fork or the new one. (Teamware didn't have branches. It always used forks. I believe Hg is/was the same way. Git, which is what I have to use nowadays, has branches but I find little use for them.) Marko -- https://mail.python.org/mailman/listinfo/python-list