On 9/25/08, bugs buggy [EMAIL PROTECTED] wrote:
On 9/23/08, Per Inge Mathisen [EMAIL PROTECTED][EMAIL PROTECTED]
wrote:
One idea: How about using just one repository, but shaped like this:
trunk/
branches/
tags/
then a next level (example from inside trunk):
trunk/code/
trunk/data/
trunk/originals/
so if you wanted to download the latest of all, you would do svn up on
trunk, while if you wanted to just grab a new code branch, you'd do
svn up on trunk/code only.
I do not see what you gain from using separate repositories, instead
of separate directories inside a single repository. Am I missing
something? I think it is a feature that with a single repository we
would still have one global revision ID for everything, so you could
say, test revision NNN, instead of test code revision NNN with data
revision MMM.
What you suggest would be fine.
I just wasn't sure if it is better (or allowed) to have one big repository
or not.
If we do have a size limit, it is better to find out from GNA now, rather
than running into this later.
With the upcoming release of the FMV patch in trunk, *before* we add the
fmvs into the repo, I would like to confirm the data structure.
trunk/data (only pumpkin official stuff, + derivatives of their work?)
trunk/code or trunk/source
trunk/FMVs (since it is optional?)
trunk/tools (for editors, utilities, and whatever else)
trunk/3rdparty (*If* we go this route. Though, I rather not.)
The main reason I don't think we should have 3rd party content in the repo
is:
a) they need access to the repo in order to fix/modify/change it.
b) if we include a mod or two, we are obligated to stick all the other mods
that people make.
c) license issues.
d) we got lots of other good content that *isn't* in the repo (lots of nice
music available on the forums), and it doesn't seem fair to include only
some stuff, and not other stuff.
e) filling up the repo without a real good reason with the extra data.
Therefore, I think it is best that we remove all 3rd party mods that we
have, and instead of the repo, stick them where they belong, like
http://download.gna.org/warzone/ or perhaps a dedicated page on the main
site.
This would even out the playing field, and not clog up the repo with extra
files.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
