CVS/Subversion: Which do you use? What's best?
by __.___._ · in General Discussion · 08/06/2003 (7:57 am) · 48 replies
Hello all. First off this is not a question about how to use CVS but rather how *you* use CVS. I am currently in the process of conducting research into what version systems game developers use and in order for my research to be effective I need as much feedback from you guys as possible. So if you could help me I would be most appreciative. Anyway to continue.
I would like to know what versioning system you are using; CVS, Subversion, or something else? What do you like about the one you use? What do you hate about the one you use? Do you use it to version and store binary files (i.e. 3D models)? How do you feel about the branching and merging features of your chosen system?
Also If you have any comments then please lets hear them.
I would like to know what versioning system you are using; CVS, Subversion, or something else? What do you like about the one you use? What do you hate about the one you use? Do you use it to version and store binary files (i.e. 3D models)? How do you feel about the branching and merging features of your chosen system?
Also If you have any comments then please lets hear them.
About the author
#42
And once again you got the problem of either picking best of breed or a large integrated package. Flexibility+more individual features vs. integrated tools.
Except for StarTeam (never used it myself) are there any other integrated, one vendor tools for total change management?
Is it even feasable to even think about one large package for all?
08/11/2003 (3:46 am)
Yeah - CVS is a very very little part of the total management of code deal.And once again you got the problem of either picking best of breed or a large integrated package. Flexibility+more individual features vs. integrated tools.
Except for StarTeam (never used it myself) are there any other integrated, one vendor tools for total change management?
Is it even feasable to even think about one large package for all?
#43
That is a good question Thomas. Here is what I understand from my research and this discussion so far. Indie developers are looking for more than just another versioning system. They need a way to manage the entire scope of their projects. The questions remains how much functionality to contain in one system so that it will still be valuable but be well within the price range of indie game developers.
The following is just a short list of what we figured would be the bare minimum for functions in a management system:
- Changelists
- Task Assignment coupled with timekeeping
- Remote functionality
- Management (managing) tracking of assigned tasks and assets and bugs
Now we realized that no one here really needs Alienbrain functionality based on the type of work that is characteristic of the indie community. Managing, as Jarrod said, seems to be the larger problem that we face.
I also see no reason why once our system is complete we can't devise a way to allow for the creation 'resources' much like what we see here for Torque to add new and needed functions as needs arise in the community. Actually I suppose it would be on our end initally to support 'feature additions' in the manner I described.
08/11/2003 (6:39 am)
Quote: "Is it even feasible to even think about oen large package for all?"That is a good question Thomas. Here is what I understand from my research and this discussion so far. Indie developers are looking for more than just another versioning system. They need a way to manage the entire scope of their projects. The questions remains how much functionality to contain in one system so that it will still be valuable but be well within the price range of indie game developers.
The following is just a short list of what we figured would be the bare minimum for functions in a management system:
- Changelists
- Task Assignment coupled with timekeeping
- Remote functionality
- Management (managing) tracking of assigned tasks and assets and bugs
Now we realized that no one here really needs Alienbrain functionality based on the type of work that is characteristic of the indie community. Managing, as Jarrod said, seems to be the larger problem that we face.
I also see no reason why once our system is complete we can't devise a way to allow for the creation 'resources' much like what we see here for Torque to add new and needed functions as needs arise in the community. Actually I suppose it would be on our end initally to support 'feature additions' in the manner I described.
#44
Either you guys are extremely rich and have lots of resources that you want to give away for cheap, or the product will be so expensive that it doesnt make sense to buy it.
As someone else stated - CVS (or any form of version control) is bare minimum. But you can do a lot within those limits, that might make a larger (and more expensive) package less attractive.
So personally I would rather see someone taking interest in e.g. subversion and adding stuff to that. It saves you from reinventing the wheel once again, while building on a community effort. Then add in integration to other "basic" modules like bugzilla etc.etc. and create add on value rather than starting from scratch.
Just my personal oppinion
08/11/2003 (12:46 pm)
I just think that most of the stuff you can get free/cheap out there has years and years of development behind them. And thats even without any form of integration between them.Either you guys are extremely rich and have lots of resources that you want to give away for cheap, or the product will be so expensive that it doesnt make sense to buy it.
As someone else stated - CVS (or any form of version control) is bare minimum. But you can do a lot within those limits, that might make a larger (and more expensive) package less attractive.
So personally I would rather see someone taking interest in e.g. subversion and adding stuff to that. It saves you from reinventing the wheel once again, while building on a community effort. Then add in integration to other "basic" modules like bugzilla etc.etc. and create add on value rather than starting from scratch.
Just my personal oppinion
#45
Except I'd rather see people pick up Katie and run with that. A config spec/filesystem setup allows you to do interesting things that are very tough to duplicate in a CVS/Subversion-style system.
08/11/2003 (12:59 pm)
I agree with Thomas. I'd much rather see contributions made to an existing project than yet another change control system that no one will be interested in.Except I'd rather see people pick up Katie and run with that. A config spec/filesystem setup allows you to do interesting things that are very tough to duplicate in a CVS/Subversion-style system.
#46
08/11/2003 (1:39 pm)
I will just say this briefly. Please don't assume that we didn't look at what was out there, or that we aren't even using an existing system to build on. But whether its built on an existing system or not - be it subversion, cvs, or whatever - what's the least, or the most you would like to see in regard to managing the entirety of a game development project?
#47
I was stating my personal oppinion in general. There are way way too many opne/closed source projects that think they can do it better than everyone else. That goes for indie gamer devs, tools, etc.
Usually when they get their fingers dirty on code stumble on the same implementation detail/problems/schedules as the other 100 projects. Just run through sourceforge which is mostly a graveyard for half baked copies of other projects.
I bet a lot of ppl that own the Torque license thought "I can make Tribes 2
08/12/2003 (1:27 am)
Sorry Ahmaud if it sounded like a personal attack or something. It's not. I've tried to see what you worked on prior to posting, but there is almost no tech/detailed info on what your system can do/builds upon.I was stating my personal oppinion in general. There are way way too many opne/closed source projects that think they can do it better than everyone else. That goes for indie gamer devs, tools, etc.
Usually when they get their fingers dirty on code stumble on the same implementation detail/problems/schedules as the other 100 projects. Just run through sourceforge which is mostly a graveyard for half baked copies of other projects.
I bet a lot of ppl that own the Torque license thought "I can make Tribes 2
#48
Our previous system was based on Photoseek, which was actually a photo management system that operated through Apache and was developed with PHP (sourceforge.net/projects/photoseek). We added revision support as well as on-the-fly creation of folder hierarchy based on a naming convention that the user defined. More info here also: www.fdfoundry.com/metazoa. We also added support for other file types. This project was done pretty quickly and too about three weeks to complete. We figured we could do the same with a better system, so we started looking around for an existing open source version system and found one called DoXFS. So actually we never have done anything from scratch and in the case of Photoseek were partially instrumental in getting the developer to pick up development of Photoseek again. Version 0.5.0 is coming soon and has better internal support for other document types, but it is not good for true management.
Now for some details about the current system we are building on, DoXFS. DoXFS relies on the XFS file system on either Linux or Irix. It uses the XFS extended attributes to store metadata. This means no database, eventually lightening speed, and no fear of database corruption since the filesystem is a journaling FS. We are porting the system from PHP, in which the RAD work was done by Joe Bacom of IBM, to C++. Our other work includes the integration of a new C++ search engine. The work will involve allowing the search engine to file through metadata within the FS as well as full text searches. DoXFS handles versioning, annotations, and provides the core server-client architecture.
Work is also being done to develop a client application. What are we using? Well we are building it on another open source system; Mozilla. The Mozilla group created a great interface language based on XML called XUL. It can now run without the entire mozilla distro thanks to a toolkit called AppRunner. Thanks to the interface kit the client should be lightweight and fast. And thankfully the folks over at mozilla are pretty helpful, as I have already discussed a few things with the developers of Firebird. Good bunch of guys over there.
That's a quick summation of what's going on down here in Georgia. Well we are located in more places than that, though the core of the group will all be located in Atlanta next year. As far as us thinking we can do it better? Well yes and no. We can pull the various tools together into one package, and a few new functions, and badabing badaboom good integrated package. So of that's considered 'better' then so be it, if not well no worries either.
08/12/2003 (5:20 am)
No, I didn't think it was a personal attack. I just didn't want you guys thinking that we were starting up another doomed project. But let me give you a bit of info on what we have done before. Our previous system was based on Photoseek, which was actually a photo management system that operated through Apache and was developed with PHP (sourceforge.net/projects/photoseek). We added revision support as well as on-the-fly creation of folder hierarchy based on a naming convention that the user defined. More info here also: www.fdfoundry.com/metazoa. We also added support for other file types. This project was done pretty quickly and too about three weeks to complete. We figured we could do the same with a better system, so we started looking around for an existing open source version system and found one called DoXFS. So actually we never have done anything from scratch and in the case of Photoseek were partially instrumental in getting the developer to pick up development of Photoseek again. Version 0.5.0 is coming soon and has better internal support for other document types, but it is not good for true management.
Now for some details about the current system we are building on, DoXFS. DoXFS relies on the XFS file system on either Linux or Irix. It uses the XFS extended attributes to store metadata. This means no database, eventually lightening speed, and no fear of database corruption since the filesystem is a journaling FS. We are porting the system from PHP, in which the RAD work was done by Joe Bacom of IBM, to C++. Our other work includes the integration of a new C++ search engine. The work will involve allowing the search engine to file through metadata within the FS as well as full text searches. DoXFS handles versioning, annotations, and provides the core server-client architecture.
Work is also being done to develop a client application. What are we using? Well we are building it on another open source system; Mozilla. The Mozilla group created a great interface language based on XML called XUL. It can now run without the entire mozilla distro thanks to a toolkit called AppRunner. Thanks to the interface kit the client should be lightweight and fast. And thankfully the folks over at mozilla are pretty helpful, as I have already discussed a few things with the developers of Firebird. Good bunch of guys over there.
That's a quick summation of what's going on down here in Georgia. Well we are located in more places than that, though the core of the group will all be located in Atlanta next year. As far as us thinking we can do it better? Well yes and no. We can pull the various tools together into one package, and a few new functions, and badabing badaboom good integrated package. So of that's considered 'better' then so be it, if not well no worries either.
Torque Owner Jarrod Roberson