RFC: Changing the way we handle sarge in the SVN (was: Re: [SVN] r360 - in /branches: cyrus-imapd-2.2_2.2.13.orig.tar.gz sarge-2.2.13/ sarge-2.2.13/debian/changelog)

[Henrique de Moraes Holschuh]

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.

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

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.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh