svn team mailing list archive

[Max Bowsher <maxb@xxxxxxx>]

On 25/03/11 16:55, Michael Diers wrote:
> The PPA now has subversion 1.6.16dfsg-1svn1 packages for Natty,
> Maverick, Lucid, Karmic, Jaunty, and Hardy.

Great, thanks :-)

> I'm afraid I slightly messed up the merge to jaunty,
> http://bazaar.launchpad.net/~svn/ubuntu/jaunty/subversion/ppa/revision/46.
> Derived files that are part of the source distribution (e.g. the
> "configure" script) have disappeared. I suppose I committed the tree
> after inadvertently running "make distclean". Should I resurrect those
> files on that branch? (Should the derived files be under version control
> in the first place?)

The general rule is "what exists in the upstream tarball from which you
derive the packaging should exist in the branch".

There's a nice easy(ish) fix here:

bzr revert -r upstream-1.6.16dfsg
bzr revert debian
bzr status

At this point you stare at the status output and wonder why it contains:

modified:
  CHANGES
  subversion/bindings/swig/python/tests/client.py

Some further poking reveals that one line of the 1.6.15 CHANGES entry
got removed in the upstream 1.6.16 release, so, set aside the Jaunty
merge issue, 'bzr revert' in the jaunty branch to throw away the results
of the previously mentioned three commands, head over to the natty
branch, and 'bzr revert -r upstream-1.6.16dfsg CHANGES', check, commit,
and merge that back step by step to Jaunty.

OK, now resume looking at Jaunty and re-execute the initial
revert-revert-status. Looking at
subversion/bindings/swig/python/tests/client.py we see it is a change
directly in the packaging branch to skip certain tests under Python 2.7,
added in Ubuntu. OK, that's an oddity, but is fine, so 'bzr revert
subversion/bindings/swig/python/tests/client.py'. Now we are ready to
commit the resurrection of the mislaid generated files, and then lastly
finish propagating the series of merges back to hardy.

And we're done. I've done all of the above and pushed the results.

> Another thing regarding bzr merge: I merged the changeset following the
> cascading of branches, natty -> maverick -> lucid -> karmic -> (jaunty,
> hardy). This was fine, except for debian/changelog, which requires some
> attention after a merge anyways. But, using this scheme, the changelog
> picks up all the interim entries from the preceding branches as well.
> 
> I guess it might be better to merge directly into the target branches,
> from the development branch that the change originates on, like so:
> natty -> ( maverick, lucid, karmic, jaunty, hardy).
> 
> Do you agree?

The debian/changelog is fiddly to merge, I agree, and there don't seem
to be any well-defined ways to manage it for multi-series backports.

However, there's a very specific reason for cascading merges backwards
series-by-series - if some change between (for example) lucid and
maverick requires special work when you backport past that point, a
cascading series of merges will carry that change into the preceding
series as required.

Max.

Attachment: signature.asc
Description: OpenPGP digital signature