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.