Boson in pkg-games svn

Miriam Ruiz little_miry at yahoo.es
Tue Jan 17 11:05:08 UTC 2006


I don't have such a great experience with svn as some of you seem to have, but
it seems a sensible design for me. We should agree on a design for svn and set
up a wiki page with an explanation so that we all can have a quick access to
it and can easily modify it if needed. What about
http://wiki.debian.org/Games/svn, http://wiki.debian.org/Games/svn_structure
or something like that?

I also think the best would be to have non-free games in a separate directory.

Greetings,
Miry

 --- Eddy Petriºor <eddy.petrisor at gmail.com> escribió:

> On 1/16/06, Joey Hess <joeyh at debian.org> wrote:
> 
> > > http://svn.debian.org/wsvn/pkg-games
> >
> > So, there are two basic layouts that can be used in a multi-package svn
> > repository, it can either look like this:
> > trunk/
> [..]
> > Or like this:
> >
> > boson-base/
> [..]
> 
> > You're using the latter layout. This layout is well suited to subversion
> > repositories consiting of several packages that are mostly checked out
> > one at a time. For example, if you want to work on all of bosun with
> > this layout you need to check out three separate trees for the three
> > packages that comprise it.
> 
> > The first layout above is better suited to subversion repositories for
> > projects where you want to be able to check out all the packages at
> > once, since it allows checking out trunk/ and getting all the packages.
> > Of course it also allows per-package checkouts (trunk/bosun-base). If
> > the repository gets really large or has some huge packages in it then
> > checking out all of trunk will become impractical, although moving
> > things into subdirectories (trunk/bosun/ for example, or
> > trunk/tetri/foo or trunk/x11/foo or whatever) can help deal with that.
> 
> 
> May I suggest:
> 
> boson-pkgs/
>     trunk/
>          boson-base/
>          boson-data/
>          boson-music/
>          boson-debian/
>              boson-base/
>              boson-data/
>              boson-music/
>    branches/
>          boson-base/
>          boson-data/
>          boson-music/
>          boson-debian/
>              boson-base/
>              boson-data/
>              boson-music/
>    tags/
>          boson-base/
>          boson-data/
>          boson-music/
>          boson-debian/
>              boson-base/
>              boson-data/
>              boson-music/
>    vendor/
>          boson-base/
>          boson-data/
>          boson-music/
> 
> In this way, one can check out the latest versions, use vendor
> branches, modifications that affect both -data and -base (which should
> be commited as one change set) can be checked in in one revision and
> use svn:externals to import under trunk/boson*/debian the
> trunk/boson-debian/boson* directory. In this way, one can easily
> import vendor branches and get  the orig.tar.gz from svn easily by svn
> export (without getting the externals, too).
> 
> More explanation follows:
> boson-pkgs/ - contains all the data for the boson packages
>     trunk/ - contains the trunk of the boson packages
>          boson-base/ - the -base project that uses
> boson-debian/boson-base/ as svn:externals   (into the debian
> directry); this is the current patched source = orig+diff
>          boson-data/  - same thing for boson-debian/boson-data
>          boson-music/  - same thing for boson-debian/boson-music
>          boson-debian/   - this contains the debian/ directory AKA the
> diff.gz; all the subfolders below this level will be used in
> boson-pkgs/trunk/boson-(base|data|music) as svn:externals into a
> directory naed debian
>              boson-base/  - debian directory for boson-base
>              boson-data/  ....
>              boson-music/  ....
> 
> I hope I was clear enough in my explanation.
> 
> 
> I have been using this system succesfully and I find it very useful
> and practical.
> (Don't worry, svn is very space-conservative when it comes to doing
> copy operations).
> 
> > There are some impacts on how things are maintained depending on which
> > layout is chosen. For example the debian perl team uses the second
> > layout, and when I was considering joining that team, I asked "how do
> > you check everything out" and there was no good answer. If I were
> > interested in doing some work on the games in our repository that cut
> > across many games, rather than focusing on one or two, then the former
> > layout would make it easier for me to check everything out.
> 
> I think that the proposed layout solves that problem and is probably
> less likely that one will port changes from one game to the other, so
> getting all the games' trunk at once does not seem to make too much
> sense, in our particular case.



		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com



More information about the Pkg-games-devel mailing list