Yeah those artists would have had a much easier life with hg. Start working, "hg pull", then change something, "hg commit", done. Only "hg add" if you create some new files, no forgetting to stage something like with git, no weird ". " in add command, no quirky extras in commands and so on. "hg push" at end of work and done.
Version Control and programming with a team
Compiled binary files have no reason to be in SOURCE control. Important ones, such as public packages of release or beta test versions, should be archived to Dropbox, network shared drives, or other types of "dumb" storage by build managers to let others download them as needed.
This is a common debate. I'm on the opposite side.
I'm a very strong believer of putting basically everything in version control.
My first test is the 'new machine install' test. I believe we should be able to take a freshly formatted machine, run a single bulk install script to put on visual studio or maya, python, perl, and all other software needed for a programmer/modeler/animator/tester configuration. Then I should be able to sync to version control and be done. This means all the third-party libraries and packages should be available through version control. If that doesn't work, I feel it is a defect to be fixed.
My second test is the 'instant demo' test. I believe we should be able to take a freshly formatted machine, run a single bulk install script, and pull down any one of a large number of builds. These should include all the nightly builds (including all debug information) for at least one month, and every build ever released outside the building (including all debug information). The list of available builds can easily go back for many years on a long-term project.
In short, we should be able to turn any machine into a demo machine, a test machine, or a development machine in just the time it takes to transfer the files and run the minimal number of installers. We should be able to re-create the exact build environment for any build over the history of the project using only an OS install disk and a version control installer and nothing more.
Over the years I have learned it is best if this is kept in a single location inside version control, rather than spread out across many network locations such as your described dropbox and network shares. Even more so for data kept in an external database -- don't do that, instead extract the data you need and store that copy of the data in version control. Since you can easily purge files from version control there is almost no space difference. It doesn't happen often, but it happens often enough that you need to re-create everything as it existed years ago. Having EVERYTHING in version control including binary files and installation files is perhaps the most reliable way to meet that need.
You do not know when you will need to pull a very historical build, including all of its debug information. We had one instance in a long-running game that we needed to re-create some of the libraries as they existed about eight years before. Our repository had well over a million submissions, but we were able to go back to that very old build, completely re-create the build environment of VS2002 and Windows 2000, install all the build tools and pipeline, and otherwise regenerate everything as needed. I'm confident we could not do that if we didn't keep EVERYTHING in version control. Having the ability enabled the studio to take advantage of a multi-million dollar deal.
There are of course people who disagree with that policy of putting everything in version control. Their logic escapes me and I usually attribute it to a lack of experience in actually NEEDING historical builds. For now it is enough to say it is a common enough disagreement point around the Internet and it is something people strongly disagree about.
I have not found a software for VC that has all the characteristics for me of full functions, agile navigation, and customization without being a jungle to learn.
Clinton
Compiled binary files have no reason to be in SOURCE control. Important ones, such as public packages of release or beta test versions, should be archived to Dropbox, network shared drives, or other types of "dumb" storage by build managers to let others download them as needed.
This is a common debate. I'm on the opposite side.
I'm a very strong believer of putting basically everything in version control.
My first test is the 'new machine install' test. I believe we should be able to take a freshly formatted machine, run a single bulk install script to put on visual studio or maya, python, perl, and all other software needed for a programmer/modeler/animator/tester configuration. Then I should be able to sync to version control and be done. This means all the third-party libraries and packages should be available through version control. If that doesn't work, I feel it is a defect to be fixed.
My second test is the 'instant demo' test. I believe we should be able to take a freshly formatted machine, run a single bulk install script, and pull down any one of a large number of builds. These should include all the nightly builds (including all debug information) for at least one month, and every build ever released outside the building (including all debug information). The list of available builds can easily go back for many years on a long-term project.
In short, we should be able to turn any machine into a demo machine, a test machine, or a development machine in just the time it takes to transfer the files and run the minimal number of installers. We should be able to re-create the exact build environment for any build over the history of the project using only an OS install disk and a version control installer and nothing more.
Over the years I have learned it is best if this is kept in a single location inside version control, rather than spread out across many network locations such as your described dropbox and network shares. Even more so for data kept in an external database -- don't do that, instead extract the data you need and store that copy of the data in version control. Since you can easily purge files from version control there is almost no space difference. It doesn't happen often, but it happens often enough that you need to re-create everything as it existed years ago. Having EVERYTHING in version control including binary files and installation files is perhaps the most reliable way to meet that need.
You do not know when you will need to pull a very historical build, including all of its debug information. We had one instance in a long-running game that we needed to re-create some of the libraries as they existed about eight years before. Our repository had well over a million submissions, but we were able to go back to that very old build, completely re-create the build environment of VS2002 and Windows 2000, install all the build tools and pipeline, and otherwise regenerate everything as needed. I'm confident we could not do that if we didn't keep EVERYTHING in version control. Having the ability enabled the studio to take advantage of a multi-million dollar deal.
There are of course people who disagree with that policy of putting everything in version control. Their logic escapes me and I usually attribute it to a lack of experience in actually NEEDING historical builds. For now it is enough to say it is a common enough disagreement point around the Internet and it is something people strongly disagree about.
You describe good practices, but for the purpose of this discussion the tools and libraries and "everything" you rightly keep under version control are source files (i.e. files needed to build the software): replacing a compiler with an updated one has the same effect as editing your own files, i.e. changing a configuration that should be recorded in source control because it affects the build results.
What has no need to be in source control are the build products, because they are never edited, replaced etc. like source code or tools; you describe situations, like setting up a test machine with a specific build, in which pulling builds from a revision control system is a convenient tool, but it remains essentially different from how actual source code is used and managed. The same level of automation and reliability can be obtained in other ways, among which shelving and forgetting build products until needed for auditing purposes as I suggested is usually more than is needed.
Even tools can be managed differently: at my workplace there are a number of read-only virtual machine images on shared drives, each configured with the tools for a different ongoing project and cloned from the result of careful manual setup; they are copied to, and run on, each developer's computer, letting people switch easily between projects without conflicts, start work on a new project easily, and reset corrupted environments to a known good state. Actual sources stay on a normal VCS. If you want to reproduce a system configuration, virtual machine images are far more reliable than rerunning install scripts and hoping the result is the same.
Keep in mind that the discussion includes people who are scared of proper version control for binary assets like images, or proper version control in general; don't ask too much of them.
We know that there are two approaches to management here, version control and source control. Both combined should be considered under software management as the total strategy for a complete grip on things, in my opinion. In some cases for developers both version control and source control are integrated by preference, especially in large software development firms. Is this not true?
At this point, I have not found a software which satisfies me to combine both version control and source control under one management software structure. I will probably be forced to do what I do in 3D art creation and put two different software (one for source control and one for version control) in the workflow pipeline for coding. 
Who here has found one software for version control and another for source control (working well together) which is more doing than learning? Please let me know. 
At this point, I have not found a software which satisfies me to combine both version control and source control under one management software structure. I will probably be forced to do what I do in 3D art creation and put two different software (one for source control and one for version control) in the workflow pipeline for coding.
Perforce.
If all you are storing is text files then get is fine. Git starts having performance issues around the 15GB mark. If all you have is text files then you won't hit that for a several years even in a corporate environment. But as you point out when you start having a large volume of frequently changing binary assets, well, you can hit the 15GB mark pretty quickly.
Perforce is expensive, it is huge, it is centralized, and it has a learning curve, but is the game industry standard for many excellent reasons (Google can describe them in depth). Perforce isn't just the games industry favorite. Microsoft uses Perforce as the core of their Source Depot that holds the core of Windows and Office and has done so for a decade. Google claims to use Perforce for over 75000 projects.
The current revision of our game's source and assets is about 300GB when downloaded. That includes not just a few hundred thousand source falls, but also some hundreds of thousands of PSDs, tens of thousands of Maya files, a massive audio clip library, and much, much more. Since we store everything in Perforce, our game's decade-long history has over 100TB because of all the binary assets since forever. Good luck distributing that over git. Across the studio we have many projects each with their own perforce server. We share a huge amount of cross-studio development work, where perforce proxies act much like a distributed version control with local copies
As for integration with other management structures, there are excellent integration tools for Perforce on just about every management system from JIRA to Mantis.
If you are a hardcore git fan, you can still use perforce --- it allows git connections where users can access a perforce clientspec as a git repository. They can do all the git work they want and when the merge it back in it goes back to the perforce mother ship. You are free to isolate your own little view of the data and pretend it is a nice small git project even when the complete project would be beyond git's abilities.
Like all systems perforce has its warts, and I normally don't recommend it for individual projects. It is expensive and difficult to learn. But if you need something to handle a whole lot of everything, then Perforce might be your answer.
If you are a hardcore git fan, you can still use perforce --- it allows git connections where users can access a perforce clientspec as a git repository. They can do all the git work they want and when the merge it back in it goes back to the perforce mother ship. You are free to isolate your own little view of the data and pretend it is a nice small git project even when the complete project would be beyond git's abilities.
Bulls-eye! That is exactly what I need to know. There is a journey of a couple years before I would need Perforce, but since Git is my current thing, that looks very promising.
Thanks, frob
Fundamentally I'm very much on the side of putting everything in (the same) version control, and being able to reliably produce a working game by just pulling from repo and building.
Part of my problem is that Unity3D seems to require or strongly encourage mixing code and data. I'm not sure if it's feasible to really clean it up, and to what degree.
If only our game code and data were properly separate, and we were able to handle missing assets sensibly on the code side, life would become a lot easier. Then we could use git, hg or whatever for the code, any other solution for the data/assets (something that is easy for the artists), and the project would still be trivial to build and work on. Specific asset sets could be designated as "official" once in a while, and the build script in the code VCS would fetch the official asset set at the time of that code version.
Part of my problem is that Unity3D seems to require or strongly encourage mixing code and data. I'm not sure if it's feasible to really clean it up, and to what degree.
If only our game code and data were properly separate, and we were able to handle missing assets sensibly on the code side, life would become a lot easier. Then we could use git, hg or whatever for the code, any other solution for the data/assets (something that is easy for the artists), and the project would still be trivial to build and work on. Specific asset sets could be designated as "official" once in a while, and the build script in the code VCS would fetch the official asset set at the time of that code version.
I think you guys are getting a bit off topic, considering the scope of the OP's question and level of experience.
deavisdude, as was already suggested, have a look at bitbucket; it supports git and mercurial repos. Private repos are free. Pick either git or merc--doesn't matter which one.
deavisdude, as was already suggested, have a look at bitbucket; it supports git and mercurial repos. Private repos are free. Pick either git or merc--doesn't matter which one.
A suggestion if you're going to be using Visual Studio for development (not sure if you are, as it hasn't been discussed). Microsoft offers Team Foundation Service/Visual Studio Online with it's newest Visual Studio versions that allow for both version control, and task allocation depending on what development model you'll be using.
I may also suggest that your team decides on what development methodology(SCRUM, Kanban, Waterfall, etc) - this will greatly determine how you setup your project development/version control system.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
