Martin Langhoff wrote:
On 8/21/05, Matthieu Moy <[EMAIL PROTECTED]> wrote:What's the future of tla 1.x? Same for 2.0. Given that the main contributors of GNU Arch--except Tom--are mostly people working now on Bazaar-NG, I _guess_ Bazaar is the way of the future.
...
This transition is tainted by the fact that patch-centric SCMs have disappointed me a bit. GIT (I am actually using cogito, which provides nice and easy shell wrappers) is patch-smart but not patch-centric, and the more I use it, the more apparent it is that is a good design decision.
Just as a point of clarification, bazaar-ng (bzr) is actually snapshot centric, rather than patch-centric. It does similar hashing for everything. But it associates a unique identifier to each hash, rather than using the hash as the identifier. (One problem with using hashes as ID is that if you do get a collision, there is nothing you can do about it.)
YMMV. Arch and other patch-centric SCMs are forever-diverging: there is nil support for identifying when two branches are identical. If a small group of developers work on their own branches, and exchange patches, most if the time you have the same tree, just different "record" of patches. GIT knows that instantaneously, and marks it as an un-branching: convergence. The trick of constantly hashing files and trees pays of handsomely.
In bzr, if I have merged from you, I generate a revision, which you can then pull into your tree, so the trees have slightly different looking history, but are effectively equivalent.
It isn't quite the same, since in git, if you and I happen to make exactly the same change, then we have the exact same tree identifiers. But there certainly is work to do merging such that you don't have the back-and-forth problem of Gnu Arch.
GIT doesn't natively do cherry-picking. It tries too hard to merge branches fully to be good at that. But you can use Stacked GIT (StGIT) which does cherry picking and many patch tricks on top of GIT. As git is doing the 'formal' SCM, StGIT stacks patches on top of a formally committed history. Patches in the stack are extremely malleable - a weirdly nice concept of being able to "edit the patch". One of git's GUIs, qgit, is poised to start doing cherrypicking, possibly based on StGIT.
I'm not sure what you mean by being able to "edit the patch". You can always do that. Even if you apply it, and then modify the code, you have effectively modified the patch.
bzr is looking to have a slightly modified patch(1) format as an emailable changeset. For basic changes, you can just use the patch program to apply it to your tree. But patch doesn't actually handle everything (it doesn't handle renames very well, and certainly doesn't track which file a patch should go to if there has been a rename in the past). For the bzr specific portions, we take advantage of the pieces that patch ignores (a header and footer, and the one line with *** before each actual patch).
OTOH, Canonical people are doing some really interesting things with bzr and hct. hct is tied to their launchpad project (there was a good talk at Debconf5 about it); I think it's interesting, specially if you are looking for patch-centric tools. Canonical has a strong driver: they need strong SCM tools to manage Ubuntu efficiently. It's a bunch to watch, even if I don't agree with the technical decisions at the core of their SCMs.
I think you need to be aware of what "the core" is. That has been the core for Gnu Arch.
Sorry again for flogging a different scm. It's strange times for Arch users, as tla is orphan and baz will probably be orphaned by Canonical at some point not too far away.
My understanding is that the reason Bazaar-NG has the NG is because they are planning on transitioning from the current Bazaar into the new one, once the research portions have been done, and various features have solidified.
From what Robert Collins has stated, each version of Bazaar, will likely incorporate a few important solid features from bzr, until eventually they are the same. With a definite road such that you will always be able to upgrade a version 1.X tree into a 1.X+1 tree.
I think their compatibility standards are slightly stricter than that. But I suppose in some ways, yes, Bazaar as it stands right now, will eventually be phased out. But only because it is evolving, not because it is being dropped on the floor.
cheers, martin pd: send flames privately if you must. please ;-)
John =:->
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnu-arch-users mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
