Latest Neocron News and Information
- New test server patch #563 has been released to Vedeena
Difference between revisions of "NcSource talk:SVN Structure"
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
+ | We have no space or bandwidth limitations on the SVN. Most artists use it as a simple drop file server, so you can arrange it how ever you feel is most efficient for working. I don't personally feel the need for a branch folder, but I guess I'm just more trusting of SVN :) --[[User:Rambus|Rambus]] 26 February 2010 | ||
+ | |||
r2d22k wants to discuss changing the setup of this svn, so go ahead mate ;) --[[User:Biglines|Biglines]] 12:32, 26 February 2010 (UTC) | r2d22k wants to discuss changing the setup of this svn, so go ahead mate ;) --[[User:Biglines|Biglines]] 12:32, 26 February 2010 (UTC) | ||
Yeah he wants to discuss this ^^ currently everything is just put into more or less one folder. i think we should change that to something like the following: | Yeah he wants to discuss this ^^ currently everything is just put into more or less one folder. i think we should change that to something like the following: | ||
− | /trunk | + | * /trunk |
− | /branch | + | * /branch |
− | /content_work | + | * /content_work |
− | /content_finished | + | * /content_finished |
− | /release | + | * /release |
the '''trunk''' folder would be the coders main working folder everything code related should go here. the substructure of this folder should look like the folderstructure the source sdk creates when you use the "create new mod" function | the '''trunk''' folder would be the coders main working folder everything code related should go here. the substructure of this folder should look like the folderstructure the source sdk creates when you use the "create new mod" function | ||
+ | |||
the '''branch''' folder will contain the sourcecode to corresponding to a specific release, i think to really be on the safe side ( i know svn normally saves all diffs but you never know what can happen) we should keep the sourcecode of every single version we release | the '''branch''' folder will contain the sourcecode to corresponding to a specific release, i think to really be on the safe side ( i know svn normally saves all diffs but you never know what can happen) we should keep the sourcecode of every single version we release | ||
+ | |||
the '''content_work''' will contain all the textures, models, maps and everything related to art that is currently being worked on. one could for example create the subfolders: textures, models, maps and sounds | the '''content_work''' will contain all the textures, models, maps and everything related to art that is currently being worked on. one could for example create the subfolders: textures, models, maps and sounds | ||
+ | |||
'''content_finished''' i'm not sure how we should structure this folder. we could for example only put the compiled .vmt, .vft and such stuff in this directory or we could move the finished models the .3ds, .bmp etc in there and put the compiled versions somewhere else | '''content_finished''' i'm not sure how we should structure this folder. we could for example only put the compiled .vmt, .vft and such stuff in this directory or we could move the finished models the .3ds, .bmp etc in there and put the compiled versions somewhere else | ||
+ | |||
'''release''' will contain the files needed on the clients we should perhaps create subfolders to distinguish between develreleases, alpha releases and beta releases. the devreleases are the releases we will use internally to test things, the alpha and beta releases will be on a milestone basis --[[User:R2d22k|R2d22k]] 12:58, 26 February 2010 (UTC) | '''release''' will contain the files needed on the clients we should perhaps create subfolders to distinguish between develreleases, alpha releases and beta releases. the devreleases are the releases we will use internally to test things, the alpha and beta releases will be on a milestone basis --[[User:R2d22k|R2d22k]] 12:58, 26 February 2010 (UTC) | ||
+ | |||
+ | (made your section a bit more readable) | ||
+ | The current setup allows people to use the ncsource folder to be synced with their game folder, mostly because in order to use hammer, model viewer etc, all the assets have to be in the game folder, which is why atm it's divided in those areas (hammer uses textures, models and entities from the game folder. Remember this is not like software development, where content not very relevant to the actual development, in this game development the content is total part of the game, as it is required for the code (for example you will need to the latest version of a model in order to code for the gun properly, placeholders might be used, but you need at least some content) | ||
+ | |||
+ | so I'd say we need a "trunk (source)" and a "trunk (game)", and maybe a branch (source) and a branch (game) (they can be subfolders of the trunk and branch). Atm we don't have a branch yet, we're still working on the first version. I dunno if we have limitless space on the svn, so maybe try to contact rambus on rearranging. --[[User:Biglines|Biglines]] 14:34, 26 February 2010 (UTC) |
Latest revision as of 16:49, 26 February 2010
We have no space or bandwidth limitations on the SVN. Most artists use it as a simple drop file server, so you can arrange it how ever you feel is most efficient for working. I don't personally feel the need for a branch folder, but I guess I'm just more trusting of SVN :) --Rambus 26 February 2010
r2d22k wants to discuss changing the setup of this svn, so go ahead mate ;) --Biglines 12:32, 26 February 2010 (UTC)
Yeah he wants to discuss this ^^ currently everything is just put into more or less one folder. i think we should change that to something like the following:
- /trunk
- /branch
- /content_work
- /content_finished
- /release
the trunk folder would be the coders main working folder everything code related should go here. the substructure of this folder should look like the folderstructure the source sdk creates when you use the "create new mod" function
the branch folder will contain the sourcecode to corresponding to a specific release, i think to really be on the safe side ( i know svn normally saves all diffs but you never know what can happen) we should keep the sourcecode of every single version we release
the content_work will contain all the textures, models, maps and everything related to art that is currently being worked on. one could for example create the subfolders: textures, models, maps and sounds
content_finished i'm not sure how we should structure this folder. we could for example only put the compiled .vmt, .vft and such stuff in this directory or we could move the finished models the .3ds, .bmp etc in there and put the compiled versions somewhere else
release will contain the files needed on the clients we should perhaps create subfolders to distinguish between develreleases, alpha releases and beta releases. the devreleases are the releases we will use internally to test things, the alpha and beta releases will be on a milestone basis --R2d22k 12:58, 26 February 2010 (UTC)
(made your section a bit more readable) The current setup allows people to use the ncsource folder to be synced with their game folder, mostly because in order to use hammer, model viewer etc, all the assets have to be in the game folder, which is why atm it's divided in those areas (hammer uses textures, models and entities from the game folder. Remember this is not like software development, where content not very relevant to the actual development, in this game development the content is total part of the game, as it is required for the code (for example you will need to the latest version of a model in order to code for the gun properly, placeholders might be used, but you need at least some content)
so I'd say we need a "trunk (source)" and a "trunk (game)", and maybe a branch (source) and a branch (game) (they can be subfolders of the trunk and branch). Atm we don't have a branch yet, we're still working on the first version. I dunno if we have limitless space on the svn, so maybe try to contact rambus on rearranging. --Biglines 14:34, 26 February 2010 (UTC)