[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: MergeOnUpstream and team policy



Jon Dowland wrote:
> 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?

(Fas answer, I'm in a hurry).

I would like to take on Joey's proposal with some restrictions:
- not all packages, I am sure that games like wormux will be huge
- I want to see this first in a branch; joeyh, feel free to make a people/joeyh branch and work in there

The main reason for this decision was space taken by the repo. This is still a big concern for me and I am sure for
others too.

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


-- 
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: