Pages: [1]
Author Topic: SVN layout  (Read 3453 times)

Cakes 35
Posts: 14520

« on: July 01, 2010, 08:33:59 PM »

How should the SVN be reorganized?

I need people experienced with SVN trees and such to help me out with concieving a new tree structure here. I'm seriously thinking of doing the 'seperate projects' idea since I only really specialize in art direction. Like divided in:

single player project - campaign management, bot files
ui project - menu files, menu graphics, console, this also includes missionpack assets
mapping project - maps, ass files, levelshots
modeling project - players, weapons, items, objectives, mapobjects
texturing project - the ambitious part. 2X sized loose replacements of map textures!
sound project - sound effects, voiceovers
music project - music, not considered sound effects here
code project - the OAX googlecode repository handles this already, though this tree would have the whole engine source in addition to the patches, for completeness. This is what the oss community would check out usually to compile, rather than all of the media data

I learned the SVN move command I should've learned about earlier, so i'm thinking, planning before actually moving. I should've done this years ago.

I also really want to add SVN users, and get this project kicked out of stagnance already. I'm already doing animation work for the 3.X branch and i'm REALLY liking my results so far. I wish I could do that for everyone in the 0.X branch, setting up ik rigs and then redoing the individual animations is no easy task.
« Last Edit: July 01, 2010, 08:50:30 PM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Posts a lot

Cakes 62
Posts: 1664

Open Arena Developer

« Reply #1 on: July 04, 2010, 11:48:33 AM »

It might be nice with a trunk and tags. I especially say tags instead of branch because they should stay static and just be there for informational purposes. Making a branch with the purpose of merging it later usually goes badly wrong. Even for stabilizing I am against branches because they have a tendency to be used a little longer than necessary.

Subversion does not know the difference between a tag or a branch only the name says if it i some thing or the other. They can be quite hard to create but they take no storage.

One might need to define further subfolders like:
modeling project/source
modeling project/pk3content
texturing project/source
texturing project/pk3content
for consistency.

I personally believe the ui project should be a subpart of the gamecode even though they are supposed to be layered there are a lot of communication between the layers.

There are nothing offending in my posts.
Pages: [1]
Jump to: