-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Leonardo Rochael Almeida wrote:
this is really nice. Observations below
Thanks! I'm CC'ing the list in case your question is in somebody else's mind.
On Thu, Apr 15, 2010 at 11:28, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[...] - - I requested that the Launchpad folks set up mirrored imports of the SVN trunks for all the ZTK projects (some were already being imported, some aren't yet done). Each project's branch can now be checked out using a nicely mnemonic bzr command, e.g.:
$ bzr branch lp:zope.interface
You can drill down to a project, and click the "Branches" tab to see any branches (most have only the one trunk branc). You can also see an overview of all the ZTK branches:
https://code.launchpad.net/zopetoolkit
I am hopeful that having the code easily branchable with a DVCS will lower the barrier to contributing at something like a bug day, for instance.
How does this impact committing? Can we use bzr to commit back to lp and it gets reflected back to svn.zope.org?
Nope, the bzr branches are "one-way" mirrors, like in an interrogation room in a police procedural TV show. (Hmm, I wonder: could this approoach be giving the ZTK the "third degree'?)
How does access-control work in this case?
Anybody with a Launchpad account can push a branch with a fix or feature change back to Launchpad. E.g., assuming that I want to work on fixing bug #12345, which maybe even has a partial suggested fix (but no full patch). First, I branch the code, run the buildout, and run the tests to get a baseline:: $ bzr clone lp:zope.interface $ cd zope.interface $ /opt/Python-2.6.5/bin/python bootstrap.py ... $ bin/buildout ... $ bin/test ... Then I add tests for the bug, and make them pass ("lather, rinse, repeat"):: $ gvim src/zope/interface # fix a bug, add a test, etc. $ bin/test ... When I'm satisfied with the fix, I commit my changes to the local branch, creating a link to the bug:: $ gvim CHANGES.txt # note the fix $ bzr commit -m "Fix LP #12345." --fixes lp:12345 Finally, I push my branch up to Launchpad:: $ bzr push lp:~tseaver/zope.interface/lp_12345 I can also create and e-mail a fully-annotated patch bundle:: $ bzr send --message="Cool feature" --mail-to=maintainer@example.com or save it as a file, e.g. to upload to the bug:: $ bzr send --message="Cool feature" \ -o /tmp/repoze.who-my_cool_feature.patch Similar development patterns would apply with hg or git, only we don't have mirrors set up for them (yet, at least).
If not, can we commit straight into svn.zope.org with bzr-svn?
I have been working directly against svn.zope.org with bzr (and git, and hg, but not as much) for the past few weeks. Given a recent enough version of each DVCS (and for bzr and hg, the svn plugin), it works pretty much just like using svn. E.g.: $ bzr co svn+ssh://svn.zope.org/repos/main/zope.interface/trunk \ zope.interface One immediate win for this (works with git and hg, too) is the "patchwork" version of the log command, which interleaves the patch for each commit with the commit metadata: $ bzr log -p A branch made using 'bzr checkout' is "bound" to the SVN repository: commits are automatically pushed back to the master. When working in bzr, I really like the ability to "batch up" local commits, so I often create a local branch of the "bound" one, hack on it with multiple commits, and then push back to the "bound" branch. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvHLhAACgkQ+gerLs4ltQ5icwCgx1siQUt9ufKsNhW7i5HtBZU9 HXgAn3uuvz+Ux/zM/Ju9k12t5nthZndv =GC9h -----END PGP SIGNATURE-----