MergeOnUpstream and team policy

[Jon Dowland <lists@alcopop.org>]

Hello,

At DebConf Eddy helped to fix a problem I was having with
SVN that boiled down to my misunderstanding of the
MergeOnUpstream property.

I really dislike it and I would like to avoid using it where
possible. I do use svn-buildpackage, but I think having
people who don't use it be able to check out or export a
trunk using normal svn is a very desirable attribute.

Today I read Joey Hess' blog[1] where he expressed the same
viewpoint and noted it was a blocker for him contributing to
the games team.

Joey suggests that the space savings are such that it is not
worth using mergeOnUpstream at all. I personally wouldn't
object to some of the larger packages using it, but I wonder
if we've actually asked the alioth admins / DSA if there is
a size concern? OR are we guilty of premature optimisation?

Can we clarify and/or revise our guidelines so that
mergeOnUpstream is optional? I'm suggesting the following
changes to <http://wiki.debian.org/Games/SVN>:

	split the "Scheme" para at "Since many games are too
	big..." and reword this sentence "Some games are
	very large. In this case, the mergeOnUpstream
	property should be used (see below)".

	Under "To import your package to SVN", remove the -o
	argument to svn-inject and add another Note below:
	"Note: for large packages, pass the -o argument to
	svn-inject. See 'mergeOnUpstream property', below".

	Add a section "mergeOnUpstream property" which
	outlines how it works and when it should be used,
	which I would suggest is best "at primary
	uploaders/importers discretion".


Thoughts/objections?

[1]
<http://kitenet.net/~joey/blog/entry/on_storing_Debian_packages_in_subversion/>


-- 
Jon Dowland