[Zope-dev] Launchpad gardening

[Gary Poster]

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 at 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.