On Thu, Jun 02, 2005 at 10:09:00AM -0300, [EMAIL PROTECTED] wrote: > P.S. A revision control tool is something which works only by interacting > intimately with one or more skilled humans. Therefore analysis of the tool > by itself in the absence of its humans users is inherently a very limited > predictor of the tool's actual value. You, John Goerzen, are someone who has > actually used darcs and arch more than trivially, so I would be interested to > hear your opinion of baz or bzr, once you actually use one of them.
I tried out baz shortly before switching to darcs, which was, if memory serves, about 2 months ago. It had fixed a few of the annoying user interface things about tla, and it fixed some of its performance problems. (tla scales to having lots of patches [where "lots" == more than 100] very poorly in many cases) But it didn't really impress me with much new, or anything that would make its branching and merging better. Maybe it's better now. I'll probably check it out again once they have those darcs-like features. Arch is well-known for its powerful branching, but I think that's because it's the first VC to gain attention that can branch across repos in any sort of sane way. Darcs branching -- and also merging -- puts it to shame. However, I know that the Arch community could make it better without very drastic changes to their on-disk format, especially where merging is concerned. Tom Lord likes to hype the tla star-merge command, but I have found it to not be very useful, and I'm not the only one with that opinion. One case where it falls on its face is if you have a repo A and a repo B, and patches are being pulled back and forth (cherry picked) between them. star-merge doesn't consider excluding patches that are already present in your tree. I often used tla replay --skip-present instead of star-merge. One other annoyance with Arch merging is that it doesn't preserve full change history. Let's say you merge 50 patches from repo A into repo B. When you commit the change, Arch commits *one* patch to repo B. It preserves all the log messages and patch names for the merged patches. But it does not preserve individual diffs for them. To get those, you'd have to go back to repo A. Worse, it's possible to make changes in repo B before committing the merge (perhaps to resolve conflicts), so even looking at those 50 patches may not yield exactly what got committed. This is one of the key things that makes merging with cherry-picked changes difficult in Arch, especially when you consider more than 2 branches. When I last used baz, it hadn't made a significant change to any of these complaints. I haven't ever tried bzr. -- John _______________________________________________ darcs-users mailing list [email protected] http://www.abridgegame.org/mailman/listinfo/darcs-users
