RFC: Changing the way we handle sarge in the SVN

Sven Mueller sm at ciphirelabs.com
Mon Apr 24 14:15:58 UTC 2006


Henrique de Moraes Holschuh wrote on 24/04/2006 04:46:
> On Sun, 23 Apr 2006, Benjamin Seidenberg wrote:
> 
>>I think maintaining a sarge backport branch is silly, since it's only
>>released once, and only differs from the main release by the changelog
>>file. I suggest an alternate approach.
> 
> That's incorrect.  Sarge backports often require a lot more than just
> changelog changes. *Currently* they are that simple, but that will not
> necessarily hold for the future.

I have to second that: Normally, Sarge backports need a lot more than
just changing debian/changelog, so I would want to keep the current
sarge branch. It just happens that the sarge branch can currently be
recreated easily from /trunk, so I do that from time to time, to make
sure it includes all the fixes.

>>Once a release is prepared and finalized, do an svn copy of trunk to
>>tags/<sarge-version>. Change the changelog there, and commit that
>>revision, uploading from the tag. It saves time and effort, and saves
>>the work of keeping the branch in sync.
> 
> I have actually come to the conclusion that not being able to really track
> what is inside a branch is too severe a hindrance, now that I got used to it
> on arch-like systems :(  But the solution to that one is to switch away from
> SVN, which is *not* something I am proposing.

Actually, now that I used an arch-like system in the company, I feel SVN
is much easier to handle. True, it is harder to keep track of which
patch is in which branch, but the plus side is that you have one
definite authority which has all the fixes (/trunk in one repository).
In the company, the trip to an arch-like system was a short one, we
reverted to SVN resp. CVS (depending on what was used for the project
before baz) after just three weeks.

> I don't know which way is worse, now:  Keeping branches in sync with the
> trunk, or reaplying all changes needed for a "function branch" (i.e. sarge
> backport) to the trunk [a copy of it, actually] every time.  But we *really*
> should pick whichever is less prone for disaster, and not whichever is
> easier.

Currently, keeping the branches in sync with trunk works relatively well
and as long as the changelog entries of the branch always includes the
patchsets applied, it is also relatively easy to make sure all necessary
patches are applied. However, since the changes between sarge branch and
/trunk are currently really small (changelog only), I do a recreation of
the sarge branch when I'm not sure wether all patches had been applied.

Same is true for the idled branch and the current (temporary)
sarge-2.2.13 branch.

cu,
sven


--
--------------------- [ SECURITY NOTICE ] ---------------------
To: pkg-cyrus-imapd-debian-devel at lists.alioth.debian.org.
For your security, sm at ciphirelabs.com
digitally signed this message on 24 April 2006 at 14:16:01 UTC.
Verify this digital signature at http://www.ciphire.com/verify.
---------------- [ CIPHIRE DIGITAL SIGNATURE ] ----------------
Q2lwaGlyZSBTaWcuAjhwa2ctY3lydXMtaW1hcGQtZGViaWFuLWRldmVsQGxpc3Rz
LmFsaW90aC5kZWJpYW4ub3JnAHNtQGNpcGhpcmVsYWJzLmNvbQBlbWFpbCBib2R5
AF8IAAB8AHwAAAABAAAAod1MRF8IAADyAgACAAIAAgAg7o/t3DzybPsZvvDtuYYY
F7x4TQO6I27g898BNr7QXyQBACAy61LAMRkBt1auhEsoSXSa0Etg0ibS51CIvYuk
5gqlIsPkklw2ME+GIg+nV0Ntl2kGlNNvKId3GLZ6kGkKTxOMU2lnRW5k
------------------ [ END DIGITAL SIGNATURE ] ------------------




More information about the Pkg-Cyrus-imapd-Debian-devel mailing list