On Thu, Jun 4, 2009 at 13:41, Gubinelli Massimiliano <[email protected]>wrote:
> * direct branching from the svn repo (bzr branch svn+shh:// > svn.sv.gnu.org/texmacs/trunk/src) The seamless integration provided by the bzr-svn is a strong point forever bzr. However it's very complex and can be hard to fix when it breaks. But as long as it works, it's great. > * possibility to publish branches on a server without having bzr installed > on the server (using only sftp) The "dumb-transport" support of bzr is also a unique feature. On the other hand, sftp transport its limitations: it does not allow multiple users to upload to the same repository (it's a limitation in sftp), and it's slower than the bzr+ssh transport (where a remote process is spawned on the remote end of the ssh link, like hg and git do). cons: > * bzr is slow in branching the svn repo (\sim 10 minutes operation for > trunk/src on my Mac) bzr-svn does a lot more work converting repositories than other tools do. If you want an apples-to-apples comparison with git, you should probably check svn fast-export and bzr fast-import. Also, if you are concerned about the performance of bzr, you should use the 1.9 format (bzr init --1.9, bzr init-repo --1.9, bzr upgrade --1.9), which is substantially faster than the default format. The default format was not changed for backwards compatibility, it will change in bzr 2.0. Do others have some advice on the choice of DCVS (keeping in mind that for > the moment I do not think that it is useful to replace svn as the main CVS > for TeXmacs)? I recently tried hg (I am inheriting a project that used it), and I discarded it after I found out that its fast-forward-on-pull behaviour makes it impossible to keep a clean mainline. I have no first-hand experience with git, but I believe it's significantly harder to use than both hg and bzr. It's a bit the same kind of different between texmacs and lyx: if you start by designing the lower level by optimizing for easy of implementation, trying to layer "ui sugar" on top leads to leaky abstractions and inconsistent behaviour. The user experience must be designed into the tool, not layered on top of it. Bzr has several lovable design choices: explicit file AND directory rename tracking, the optional separation between repositories, branches and checkouts, the hierarchical log and dotted revision numbers. It also has superior merge algorithms (weave merge and lca merge), and some very nice add-ons (bzr-gtk, bzr-svn) and has the best support for Windows. Anyway, as Norbert pointed out, the decision to switch to any DVCS is more momentous than the decision to pick either DVCS. Disclosure: I was a developer of code.launchpad.net at Canonical for 3.5 years.
_______________________________________________ Texmacs-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/texmacs-dev
