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

> On Thu, Apr 15, 2010 at 11:28, Tres Seaver <tsea...@palladion.com> wrote:
>> 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=maintai...@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 \

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 Seaver          +1 540-429-0999          tsea...@palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to