CVS/Subversion: Which do you use? What's best?

#21 It would. I would not put bugtracking in it. I want source control to be seperate from bugtracking. I also want a GOOD GUI.

#22 Now that requires a bit more discussion as to what constitutes a 'good' GUI. So what are some elements and functions that you feel the GUI should contain? Also please everyone let me know if the conlcusion I submitted sums up your feelings about what you would like to see in a version control system.

#23 Actually Pat if bug tracking is implemented correctly it is priceless to have it tightly coupled with version control and change mangement workflow is a massive time saver on content heavy multi-team member projects.

StarTeam for example does this brilliantly, "bugs" which may or may not be actual programming flaws can be tied DIRECTLY to the things they may or maynot impact. And impact analysis is one of the things missing from every stand alone bug tracking system I have ever seen.

Someone enters in a bug into the the change management system, some one reviews it and see it actually is a FLAW and not a feature request or someother non-flaw type thing. Then they can see what files it will affect, be it source code, models, textures etc. Then they can prioritize the bugs IMPACT on the entire project.

A small change to fix a minor flaw in one .h file can possibly break an entire build. Or what looks like a simple change to a .jpg file on a web site could completely muck the formatting on other pages where the resource is used but not considered by the change requestor.

All this is far from the scope of any of the other version control only systems, a complete change management solution is the way to go if at all possible.

@Ahmaud - previewing of files is extremely trival and unessary, everyone of the version control projects listed use what ever program created the files to "preview" them, even CVS can be made to do this with some effort.

I think re-writting content display code into something as vertical market as version control/changemanagement is a waste of resources. Especially when most of the files, and almost all the RAW files will require the host app anyway, 3D StudioMAX, PhotoShop PSD, and many others can't be effectively "previewed" anyway.

#24 TortoiseCVS is an immensely useful tool for working with CVS on windows. Built right into the explorer - very nice. Between it, WinCVS, and the command line tool, I've yet to find a task I can't tackle...

#25 @Jarrod: I can see where in the case of independent developers previewing of files is unnecessary, but it could apply to other uses, visual effects in particular (have had requests for such a member of the visual effects community). So in our case it wouldn't be a waste of resources to develop. I do see however that previewing might be overkill for independent game development.

However one company in particular has expressed a desire to actually have previewing of assets, a la, alienbrain. They tested it and while it was not quite out of their price range it still didn't do what they needed for the price they wanted to pay. They also really liked the visual annotation feature - scribbles.

Since I am gaining a better understanding of what versioning systems you use and how let me move into another area of this discussion. I presume that using CVS or subversion would be the minimum you would require or want in a version - as well as production tracking, bugtracking - control system. Am I correct in assuming this? If so what's the next level for you as game developers? Do you feel you need this 'next level' to manage the projects?

Just to point out one developer I did have discussions with needed a way to track the actual time spent on assigned tasks for developers. Especially those who are contracted. So what useful and needed features, much like this one, are also needed by independent developers?

#26 @Ahmaud - preview of "cooked" files in a thumbnail fashion is one thing, which as alienbrain shows is not much help or very effective. Since what you want to version control and change manage is the RAW resources that are used to generate the "cooked" file formats.

Using torque as an example, .dts and .dif files are "cooked" files, and a preview would not be much use, all you really need to know is which VERSION is the "latest" one that should be used in a build.

Now .map files create .dif files, but they are not something you would version since they are intermediate files and can be generated at anytime from what ever format your tool uses natively. You would version control the native WorldCraft or Quark or Cartograpy Shop files and a "preview" of one of those files would not be very meaningful. Even a thumbnail would not be very meaningful because it would not convey any contextual information about the version. You would actually have to OPEN the file in its native application to see if it is the one you wanted. 99% of the time you use the last known "good" file, the previous versions are usually used when you much up the current version and need to start over from a known good point.

Production tracking can be done with TAGs or simlar CONVENTIONS but since they are only CONVENTION they are not programmtically enforceable ( read human error still creeps in at the worst possible moment ).

Bugtracking I believe should be tightly tied to the versioning. Because I work with extremely large code bases most of the time, QA can be testing something and the currect dev version might be waaaaay ahead. So when a bug is submitted I like to know what version of the files might be wrong, lots of times problems get fixed after shipping to QA but before QA actually finds them.

Build system integration is a much for what I like. It is called continuous integeration, which means the build runs constantly and un-attended. And QA can deploy/redeploy any version they want to see if bugs have been fixed or not.

Testors should be automatically alerted to every successful build and have a very easy way to get any version of the build and deploy/install or redeploy/uninstall as a one step process.

There are plenty of good bad and ugly team/project management tools. I usually use something that is available online and web enabled if most of the team is remote.

CVS is better than nothing, but there are lots of better alternatives than CVS. I use CVS everyday on a couple of my clients projects, but for inhouse I use much better tools.

#27 Jarrod, how does QA figure out which files to associate with the bugs?

I've seen systems that know how to tie bugs to given sets of checkins, so you know where a bug was resolved, but trying to tie a bug to a given file before the problem is fully investigated seems to be problematic at best.

#28 WinCVS setup easy and works for me. I will leave it at that.

#29 How many that have replied are primarily programmers? How many of you are artists? And finally how many of you do both programming and art? I know that as independent developers you wear many hats but it seems that the people who have responded are primarily programmers. Am I correct in assuming this?

#30 Programmer here - using CVS. Why? Costs, its installed on most systems I know per default and "its what I'm used too". It does the job - weird sometimes, but it works.

Command line CVS only though. I hate wincvs, and I would love to have some better gui.

Our artists use CVS too, but they dont like it. They are not used to saving their raw work in a version system.

yes - small team...

#31 Thomas - you should try Tortoise.

Ahmaud - I'm a programmer. I can do art, but prefer to leave it to others.

#32 @Mark - simple QA assigns a flaw to a particular component of the system, Something like StarTeam allows for foward and backward dependancy relationships on any file. So either the component ( file group ) is selected and the bug report filed against that.

someone on the programming team usually team lead reviews all the bug reports before assigning them priorities and developers, so they can do impact analysis before the programmer gets it.

When I have a team working for me, I spend most of my day between designing new functionality and refactoring and assigning/priortizing tasks.

Most people don't talk about it, but the largest percentage of "bugs" reported are not flaws in the system, they are either feature requests, user/testor not understanding how the system is supposed to work ( training issues ) for many reasons or testors that want to be designer/engineer/architects . The small percentage that is left are real flaws that made it thru unit testing.

#33 So perhaps it would be prudent to allow a developer to specify if it is a true 'bug', that being a flaw, or a feature request from user/testers/developers. This would actually fit in with the context system we plan on implementing. Then the team members could see "bugs" defined according to their context; whether that be flaws in the system or feature requests.

#34

Quote:@Mark - simple QA assigns a flaw to a particular component of the system, Something like StarTeam allows for foward and backward dependancy relationships on any file. So either the component ( file group ) is selected and the bug report filed against that.

Just about every bug tracking system I've seen accepts a component string (or allows a pick from a drop down). Is Starteam doing something different? I haven't been exposed to that package yet. I'm afraid I still don't understand what benefit tying this to the version control system gives. Could you explain a bit mote?

Ahmaud: Lots of bug tracking systems have not-a-bug or enhancement catagories. Have you tried installing bugzilla or similar? You'll probably find a lot of good ideas there if you want to add a bug tracking system to your version control system.

#35 I have briefly looked at Bugzilla. One thing I do like about bugzilla is how you can add and follow comments, a form of annotations I suppose, through the system(via web interface). Having those comments summed up in a viewer that could be recalled at any instance might be nice though. Hmmm, now that's an idea.

However I would still want to have entries catagorized, most likely via a DAG (Direct Acyclical Graph - a form of knowledge discovery and data mining), in the system. Context based views would provide a more concise way to manage mounds of information, or just quickly see what you want or need to see. Google is a good example of knowledge discovery for the web. I suppose you could say we are trying to implement a system such as this for asset versioning, albeit much simpler.

#36 Another thing to remember is to have someone that ASSIGNS tasks to the programers, otherwise they will cherry pick and none of the greasy problems will get solved only the easy ones.

@Mark - it is just not a string that by convention creates the tracking, it actually allows you to link the files as dependancys, so you can do real honest impact analysis and see if you change something how it affects the entire system.
I have worked on many large systems in the past where someone makes what appears to be small change to something and the effects cascade down to break other things in very subtle ways, and you end up chasing your tail trying to figure out why something is behaving incorrectly and there is no APPARENT change.

A good Change Management system is just that it helps you MANAGE change, not just track change. Versioning is just a small piece to the puzzle of change management and project managment.

#37 Jarrod has a lot of good things to say.

I'm gonna try out Subversion...the key thing is CHANGELIST.

#38 Yeah, I talked with Joe from Bravetree and he said one of the biggest needs they had was CHANGELIST support. He said that's one of the many things they like about Perforce. I agree with Pat, Jarrod you have had some great things to say about it.

As far as Assignments go there will be a production module that allows for both creation, managing and tracking of assigned developer tasks. Which leads us to the issue of workflow management. I think workflow contains the very issues you have addressed Jarrod. Such as managing changes as well as tracking them. This of course spanning over the initial code development and the process of fixing bugs, or adding enhancements to the system. CHANGELISTS, are of course one component of this.

#39 Thanks Pat and Ahmaud, unfortunately I learned all these lessons the hard way, usually about 2AM when something was due the next morning.

My feeling is no matter how small or large a project is, these change management issues will still be issues.

Subversion does look like the project that will replace CVS, if they can get the compelling features implemented and a GUI that works and is reliable it will definately be the number 1 alternative to CVS.

#40 At first I started just using the released versions of Torque and recommended everyone to use latest released version instead of CVS so that everything can be compatible, but recently about a month or two ago I think using CVS version for game development isn't really a bad idea. It has good fixes and it works pretty good. There are other reasons which I cannot think of so I hope other people will point those out for me. :)