Re: [Zope-dev] Launchpad gardening
-----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-----
On Thu, Apr 15, 2010 at 12:17 PM, Tres Seaver <tseaver@palladion.com> wrote: <snip>
Finally, I push my branch up to Launchpad::
$ bzr push lp:~tseaver/zope.interface/lp_12345
Once the branch is submitted to Launchpad, it is also possible to create a Merge Proposal, which is a step up from a patch. Reviewers can see a live diff on the Merge Proposal that gets updated every time you do a new 'push'. Merge Proposals also have their own state. There's a dashboard for keeping track of pending and approved Merge Proposals, eg: https://launchpad.net/zopetoolkit/+activereviews (the same exists for users: https://launchpad.net/~sidnei/+activereviews) If you have bzrtools installed, you can use the 'bzr lp-submit' command to create a Merge Proposal from the command line, IIRC. It might seem like extra work at first, but once you get used to using Merge Proposals to track work that's pending a merge it pays off very quickly. <snip>
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.
That's how I work too, even with branches stored in bzr, by having a 'trunk' branch that is bound it saves you a few steps when merging work back into the main tree. For people that prefer to be really explicit, you can use 'bzr branch svn+ssh://...' instead of 'bzr checkout' to create an unbound branch by default. You can also use 'bzr bind' and 'bzr unbind' to switch between bound and unbound. -- Sidnei
There's a dashboard for keeping track of pending and approved Merge Proposals, eg:
Not very useful since it's empty. Look at the pending proposals from zc.buildout for a better example: https://edge.launchpad.net/zc.buildout/+activereviews -- Sidnei
Thanks Tres and Sidnei, My questions were intended to go to the list anyway. Can we take a branch from the launchpad mirror and bind it back directly at svn+ssh://svn.zope.org/ to commit? For instance, say I'm reviewing a bugfix proposed by someone that doesn't currently have access to svn.zope.org but added a merge-proposal to lp, can I branch it, bind it to svn+ssh://svn.zope.org and then commit? Wouldn't it be nice if it was possible? Cheers, Leo On Thu, Apr 15, 2010 at 12:34, Sidnei da Silva <sidnei.da.silva@gmail.com> wrote:
On Thu, Apr 15, 2010 at 12:17 PM, Tres Seaver <tseaver@palladion.com> wrote: <snip>
Finally, I push my branch up to Launchpad::
$ bzr push lp:~tseaver/zope.interface/lp_12345
Once the branch is submitted to Launchpad, it is also possible to create a Merge Proposal, which is a step up from a patch. Reviewers can see a live diff on the Merge Proposal that gets updated every time you do a new 'push'. Merge Proposals also have their own state.
There's a dashboard for keeping track of pending and approved Merge Proposals, eg:
https://launchpad.net/zopetoolkit/+activereviews
(the same exists for users: https://launchpad.net/~sidnei/+activereviews)
If you have bzrtools installed, you can use the 'bzr lp-submit' command to create a Merge Proposal from the command line, IIRC.
It might seem like extra work at first, but once you get used to using Merge Proposals to track work that's pending a merge it pays off very quickly.
<snip>
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.
That's how I work too, even with branches stored in bzr, by having a 'trunk' branch that is bound it saves you a few steps when merging work back into the main tree. For people that prefer to be really explicit, you can use 'bzr branch svn+ssh://...' instead of 'bzr checkout' to create an unbound branch by default. You can also use 'bzr bind' and 'bzr unbind' to switch between bound and unbound.
-- Sidnei
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Leonardo Rochael Almeida wrote:
Thanks Tres and Sidnei,
My questions were intended to go to the list anyway.
Can we take a branch from the launchpad mirror and bind it back directly at svn+ssh://svn.zope.org/ to commit?
For instance, say I'm reviewing a bugfix proposed by someone that doesn't currently have access to svn.zope.org but added a merge-proposal to lp, can I branch it, bind it to svn+ssh://svn.zope.org and then commit?
Wouldn't it be nice if it was possible?
It is possible, at least in theory. I have tried that out on my local machine:: $ cd /tmp $ mkdir wibn $ cd wibn/ $ svnadmin create svn-repo $ svn mkdir -m "Wouldn't it be nice?" file:///`pwd`/svn-repo/wibn $ svn mkdir -m "Wouldn't it be nice?" file:///`pwd`/svn-repo/wibn/trunk $ svn co file:///`pwd`/svn-repo/wibn/trunk svn-trunk $ cat > svn-trunk/nice.txt Wouldn't it be nice if we were older and we didn't have to wait so long? ^D $ svn add svn-trunk/nice.txt $ svn commit -m "Sing." svn-trunk/nice.txt $ mkdir bzr-repo $ bzr init-repo bzr-repo $ cd bzr-repo/ $ bzr co file:///`cd .. && pwd`/svn-repo/wibn/trunk bzr-trunk $ bzr branch bzr-trunk non-commital $ cd non-commital/ $ gvim nice.txt # add more lyrics $ bzr commit -m "Sing more." $ bzr push file:///`cd ../.. && pwd`/svn-repo/wibn/trunk $ cd ../../svn-trunk/ $ svn up $ cat nice.txt # see the changes I'm not quite sure how it will work for pushing to SVN from a branch made against the Launchpad mirror of SVN: there are a few more possible points of disconnection in that path. Maybe Sidnei already works this way? 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 iEYEARECAAYFAkvHQRoACgkQ+gerLs4ltQ4wNACdE9SWMrx/tIxHL1C8cFvauN+w U9kAoMBt21n24BIUXW+Sf9HYU2HIVrlK =G69T -----END PGP SIGNATURE-----
On Thu, Apr 15, 2010 at 12:41 PM, Leonardo Rochael Almeida <leorochael@gmail.com> wrote:
Thanks Tres and Sidnei,
My questions were intended to go to the list anyway.
Can we take a branch from the launchpad mirror and bind it back directly at svn+ssh://svn.zope.org/ to commit?
For instance, say I'm reviewing a bugfix proposed by someone that doesn't currently have access to svn.zope.org but added a merge-proposal to lp, can I branch it, bind it to svn+ssh://svn.zope.org and then commit?
Wouldn't it be nice if it was possible?
Not sure if it would. What you really want to do is to merge the bzr branch you got from Launchpad into the 'trunk' you got from svn.zope.org, which behaves exactly as Tres described on his previous email. Pushing the branch directly without merging first would overwrite the contents of the target branch with the contents of the pushed branch. -- Sidnei
On Apr 15, 2010, at 12:51 PM, Sidnei da Silva wrote:
On Thu, Apr 15, 2010 at 12:41 PM, Leonardo Rochael Almeida <leorochael@gmail.com> wrote:
Thanks Tres and Sidnei,
My questions were intended to go to the list anyway.
Can we take a branch from the launchpad mirror and bind it back directly at svn+ssh://svn.zope.org/ to commit?
For instance, say I'm reviewing a bugfix proposed by someone that doesn't currently have access to svn.zope.org but added a merge-proposal to lp, can I branch it, bind it to svn+ssh://svn.zope.org and then commit?
Wouldn't it be nice if it was possible?
Not sure if it would. What you really want to do is to merge the bzr branch you got from Launchpad into the 'trunk' you got from svn.zope.org, which behaves exactly as Tres described on his previous email. Pushing the branch directly without merging first would overwrite the contents of the target branch with the contents of the pushed branch.
I didn't think this was true, so I checked another source. :-) bzr does not allow that, actually--at least for bzr branches, and I suspect for svn branches. If the branches are diverged, you can't just push. You need to merge and then push. But, my source for bzr knowledge warns me, "if you merge with the public version, and then try to push to the public version, your revno will change, and that will confuse people." So, a better story is to use bzr as if it were svn at that point: bzr co the trunk, bzr merge your changes, and bzr commit. If the Launchpad import of a given SVN package was recently created (since late 2009) then it works quite nicely. If it was made earlier, you will encounter hiccups. With the new imports I've done stuff like this. - bzr branch the import from LP. - Make changes locally and commit. - push branch to LP - make a merge proposal on LP and get a review - bzr push the branch to a new branch on zope's svn (each commit you made locally shows up separately even though it is one big push) - bzr co the svn trunk, merge my changes, and commit. It's quite nice. Handling merges is wildly nicer in the correct dvcs options than svn. The only limitation for bzr right now is that bzr doesn't handle svn externals. That's slated to change this year, I think. If people are curious, Sidnei or I could reach out and get more details of the timeline. Gary
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Poster wrote:
On Apr 15, 2010, at 12:51 PM, Sidnei da Silva wrote:
On Thu, Apr 15, 2010 at 12:41 PM, Leonardo Rochael Almeida <leorochael@gmail.com> wrote:
Thanks Tres and Sidnei,
My questions were intended to go to the list anyway.
Can we take a branch from the launchpad mirror and bind it back directly at svn+ssh://svn.zope.org/ to commit?
For instance, say I'm reviewing a bugfix proposed by someone that doesn't currently have access to svn.zope.org but added a merge-proposal to lp, can I branch it, bind it to svn+ssh://svn.zope.org and then commit?
Wouldn't it be nice if it was possible? Not sure if it would. What you really want to do is to merge the bzr branch you got from Launchpad into the 'trunk' you got from svn.zope.org, which behaves exactly as Tres described on his previous email. Pushing the branch directly without merging first would overwrite the contents of the target branch with the contents of the pushed branch.
I didn't think this was true, so I checked another source. :-)
bzr does not allow that, actually--at least for bzr branches, and I suspect for svn branches. If the branches are diverged, you can't just push. You need to merge and then push.
But, my source for bzr knowledge warns me, "if you merge with the public version, and then try to push to the public version, your revno will change, and that will confuse people." So, a better story is to use bzr as if it were svn at that point: bzr co the trunk, bzr merge your changes, and bzr commit.
If the Launchpad import of a given SVN package was recently created (since late 2009) then it works quite nicely.
If it was made earlier, you will encounter hiccups.
With the new imports I've done stuff like this.
- bzr branch the import from LP. - Make changes locally and commit. - push branch to LP - make a merge proposal on LP and get a review - bzr push the branch to a new branch on zope's svn (each commit you made locally shows up separately even though it is one big push) - bzr co the svn trunk, merge my changes, and commit.
It's quite nice. Handling merges is wildly nicer in the correct dvcs options than svn.
The only limitation for bzr right now is that bzr doesn't handle svn externals. That's slated to change this year, I think. If people are curious, Sidnei or I could reach out and get more details of the timeline.
- From my research, support for svn:externals in bzr-svn is actually blocked on an upstream bzr feature which is itself stalled (no activity for 2 years now, I think). svn:externals are already kind of a wart, although recent SVN versions have fixed one long-standing issue (they allow relative externals now). I think we have a few recurring patterns in the repository: - using an external to pull in $ZSVN/bootstrap, rather than copying the bootstrap.py file. I'm ambivalent here, and could easily see dumping the external. - using an external to work around setuptools' inablility to install headers in a useful way, e.g. Zope's 'include' directory. Maybe a new recipe would be better? - using externals to stitch together omnibus buildouts, e.g. CMF.buildout. We could probably use something like 'infrae.subversion' instead, maybe with a hook that allowed local customization of the command used to fetch the sub-checkout. 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 iEYEARECAAYFAkvHTH4ACgkQ+gerLs4ltQ5imwCgz9YvLWyVMqRTJbqgjYPntzGg FE8AnR0LZivfJM9tjC5TJI2uTQmV3LZE =N1uu -----END PGP SIGNATURE-----
On Apr 15, 2010, at 1:27 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gary Poster wrote:
On Apr 15, 2010, at 12:51 PM, Sidnei da Silva wrote:
On Thu, Apr 15, 2010 at 12:41 PM, Leonardo Rochael Almeida <leorochael@gmail.com> wrote:
Thanks Tres and Sidnei,
My questions were intended to go to the list anyway.
Can we take a branch from the launchpad mirror and bind it back directly at svn+ssh://svn.zope.org/ to commit?
For instance, say I'm reviewing a bugfix proposed by someone that doesn't currently have access to svn.zope.org but added a merge-proposal to lp, can I branch it, bind it to svn+ssh://svn.zope.org and then commit?
Wouldn't it be nice if it was possible? Not sure if it would. What you really want to do is to merge the bzr branch you got from Launchpad into the 'trunk' you got from svn.zope.org, which behaves exactly as Tres described on his previous email. Pushing the branch directly without merging first would overwrite the contents of the target branch with the contents of the pushed branch.
I didn't think this was true, so I checked another source. :-)
bzr does not allow that, actually--at least for bzr branches, and I suspect for svn branches. If the branches are diverged, you can't just push. You need to merge and then push.
But, my source for bzr knowledge warns me, "if you merge with the public version, and then try to push to the public version, your revno will change, and that will confuse people." So, a better story is to use bzr as if it were svn at that point: bzr co the trunk, bzr merge your changes, and bzr commit.
If the Launchpad import of a given SVN package was recently created (since late 2009) then it works quite nicely.
If it was made earlier, you will encounter hiccups.
With the new imports I've done stuff like this.
- bzr branch the import from LP. - Make changes locally and commit. - push branch to LP - make a merge proposal on LP and get a review - bzr push the branch to a new branch on zope's svn (each commit you made locally shows up separately even though it is one big push) - bzr co the svn trunk, merge my changes, and commit.
It's quite nice. Handling merges is wildly nicer in the correct dvcs options than svn.
The only limitation for bzr right now is that bzr doesn't handle svn externals. That's slated to change this year, I think. If people are curious, Sidnei or I could reach out and get more details of the timeline.
- From my research, support for svn:externals in bzr-svn is actually blocked on an upstream bzr feature which is itself stalled (no activity for 2 years now, I think).
Yes. That's the thing that should be worked on soonish.
svn:externals are already kind of a wart, although recent SVN versions have fixed one long-standing issue (they allow relative externals now). I think we have a few recurring patterns in the repository:
- using an external to pull in $ZSVN/bootstrap, rather than copying the bootstrap.py file. I'm ambivalent here, and could easily see dumping the external.
- using an external to work around setuptools' inablility to install headers in a useful way, e.g. Zope's 'include' directory. Maybe a new recipe would be better?
Not clear if it would help, but I'm actively maintaining z3c.recipe.filetemplate. In the process of adding support for relative paths.
- using externals to stitch together omnibus buildouts, e.g. CMF.buildout. We could probably use something like 'infrae.subversion' instead, maybe with a hook that allowed local customization of the command used to fetch the sub-checkout.
That would be cool.
On Thu, Apr 15, 2010 at 2:27 PM, Tres Seaver <tseaver@palladion.com> wrote:
- using externals to stitch together omnibus buildouts, e.g. CMF.buildout. We could probably use something like 'infrae.subversion' instead, maybe with a hook that allowed local customization of the command used to fetch the sub-checkout.
I'd recommend mr.developer then, if you haven't looked at it yet. http://pypi.python.org/pypi/mr.developer I believe it *might* be using infrae.subversion under the covers, though I'm not 100% confident. The nice thing it adds on top of that is switching between a release version and a checkout in a single command, IIRC. -- Sidnei
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sidnei da Silva wrote:
On Thu, Apr 15, 2010 at 2:27 PM, Tres Seaver <tseaver@palladion.com> wrote:
- using externals to stitch together omnibus buildouts, e.g. CMF.buildout. We could probably use something like 'infrae.subversion' instead, maybe with a hook that allowed local customization of the command used to fetch the sub-checkout.
I'd recommend mr.developer then, if you haven't looked at it yet.
http://pypi.python.org/pypi/mr.developer
I believe it *might* be using infrae.subversion under the covers, though I'm not 100% confident. The nice thing it adds on top of that is switching between a release version and a checkout in a single command, IIRC.
What, y'all haven't hacked bzr support into it yet? They support svn, cvs, hg, git... :) 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 iEYEARECAAYFAkvHhnoACgkQ+gerLs4ltQ6B1ACgyTx8xbL/4MGwgnW0RmRRH5cN wEoAoKLcqUJGwdFZRTfMnIJ1R9aNWdRU =8jt0 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
Sidnei da Silva wrote:
On Thu, Apr 15, 2010 at 2:27 PM, Tres Seaver <tseaver@palladion.com> wrote:
- using externals to stitch together omnibus buildouts, e.g. CMF.buildout. We could probably use something like 'infrae.subversion' instead, maybe with a hook that allowed local customization of the command used to fetch the sub-checkout. I'd recommend mr.developer then, if you haven't looked at it yet.
I believe it *might* be using infrae.subversion under the covers, though I'm not 100% confident. The nice thing it adds on top of that is switching between a release version and a checkout in a single command, IIRC.
What, y'all haven't hacked bzr support into it yet? They support svn, cvs, hg, git... :)
Turns out not to be too tough, given the git and mercurial examples to stare at: lp:~tseaver/mr.developer/bzr_sources I have only tested it lightly so far, but it does seem at least to get the initial checkouts done using bzr (even against svn+ssh:// URLs!). 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 iEYEARECAAYFAkvHsfkACgkQ+gerLs4ltQ5EuwCfYWPBrAnkv/zfUrS966+CBW1b Ak4AoKiqOMfA5HnYi+oBmU00knWxeioH =EoOV -----END PGP SIGNATURE-----
On Thu, Apr 15, 2010 at 9:40 PM, Tres Seaver <tseaver@palladion.com> wrote:
Turns out not to be too tough, given the git and mercurial examples to stare at:
lp:~tseaver/mr.developer/bzr_sources
I have only tested it lightly so far, but it does seem at least to get the initial checkouts done using bzr (even against svn+ssh:// URLs!).
I tried to get this branch, but it depends on lp:~tseaver/mr.developer/trunk, which hasn't been pushed to. -- Sidnei
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sidnei da Silva wrote:
On Thu, Apr 15, 2010 at 9:40 PM, Tres Seaver <tseaver@palladion.com> wrote:
Turns out not to be too tough, given the git and mercurial examples to stare at:
lp:~tseaver/mr.developer/bzr_sources
I have only tested it lightly so far, but it does seem at least to get the initial checkouts done using bzr (even against svn+ssh:// URLs!).
I tried to get this branch, but it depends on lp:~tseaver/mr.developer/trunk, which hasn't been pushed to.
Ugh. I reassigned ownership of the trunk branch to 'mr.developer-team', and made Florian Schulze a member of the team, so that I would be "poaching". I guess I should delete my branch and re-push from a checkout of my git repository? 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 iEYEARECAAYFAkvIuggACgkQ+gerLs4ltQ4MCACcDq+1+g0PW/1DBrHx1gLIG89W t3AAn0yN3y+IuzVTAw7u0wu5UHBoxBYk =70xy -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
Sidnei da Silva wrote:
On Thu, Apr 15, 2010 at 9:40 PM, Tres Seaver <tseaver@palladion.com> wrote:
Turns out not to be too tough, given the git and mercurial examples to stare at:
lp:~tseaver/mr.developer/bzr_sources
I have only tested it lightly so far, but it does seem at least to get the initial checkouts done using bzr (even against svn+ssh:// URLs!). I tried to get this branch, but it depends on lp:~tseaver/mr.developer/trunk, which hasn't been pushed to.
Ugh. I reassigned ownership of the trunk branch to 'mr.developer-team', and made Florian Schulze a member of the team, so that I would be "poaching". I guess I should delete my branch and re-push from a checkout of my git repository?
That repository is here: http://github.com/tsesver/mr.developer 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 iEYEARECAAYFAkvIx6QACgkQ+gerLs4ltQ72WgCZAaD3hDzPELSiI/u7En/IbWHs 5kMAn26uucC0V6X9ND8ipPRuOWsfkA6X =43dE -----END PGP SIGNATURE-----
participants (4)
-
Gary Poster -
Leonardo Rochael Almeida -
Sidnei da Silva -
Tres Seaver