Timeline for Version control for game development - issues and solutions?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 10, 2012 at 21:48 | history | edited | Klaim | CC BY-SA 3.0 |
Now Mercurial provide largefile extension by default, this need update.
|
| Dec 22, 2011 at 13:22 | comment | added | Klaim | @talljosh From v2.x, Mercurial now provide the largefiles extension by default, so you can update the part about the BigFile extension. | |
| Aug 24, 2011 at 15:37 | history | tweeted | twitter.com/#!/StackGameDev/status/106389747525615616 | ||
| Sep 10, 2010 at 22:06 | comment | added | dash-tom-bang | Regardless of bigfile support, if two people edit, say, a Maya file at once, one will check in and the other will have to redo the work. With Perforce, at least, you can know that someone else is editing the file (and also automatically have a lock on that file). | |
| Aug 18, 2010 at 10:44 | comment | added | Kylotan | @280Z28: this is also an issue we found for any files if you have a policy that any new code needs to be tested against the latest build. Otherwise you can find that when you come to push your tested code, someone else has committed new changes, so you have to pull, merge, and repeat your tests. Obviously this could go on indefinitely. | |
| Aug 9, 2010 at 0:19 | comment | added | talljosh | 280Z28, have you come across any distributed VCS which has a solution to that problem? Having a lock would seem to me to defeat one of the premises of distributed version control---that you don't have a central server and don't necessarily know the location of all check-outs. | |
| Aug 7, 2010 at 11:43 | comment | added | Sam Harwell |
There doesn't seem to be an option comparable to svn:needs-lock, and since there's also no way to tell who's locally working on what files, you're back to passing a bowl around the team, literally (you aren't allowed to edit without the bowl on your desk). BigFiles extension or not, this VCS is useless for binary files without a practical solution to this.
|
|
| Aug 6, 2010 at 14:17 | comment | added | Kylotan | With regards to large projects - TortoiseHg appears to go much slower on a large repository with 8 years of revisions than it does on a small repository with less than 20 revisions. I don't yet know whether this is something specific to Tortoise or to Mercurial more generally. | |
| Aug 6, 2010 at 12:13 | comment | added | jacmoe | +1 for Mercurial. It's fast, easy to use, and surprisingly powerful. :) I am using it for everything: web development, game development, private one-person projects and team projects. Thanks for introducing the BigFiles extension! | |
| Jul 16, 2010 at 17:55 | history | edited | Cyclops | CC BY-SA 2.5 |
added 131 characters in body
|
| Jul 16, 2010 at 13:30 | comment | added | Cyclops | Interesting note about the Bigfiles Extension - that addresses one of the problems reported in the original thread, that Distributed VCS wouldn't fit well with game productions that had large numbers of binary file assets. | |
| Jul 16, 2010 at 6:19 | history | edited | talljosh | CC BY-SA 2.5 |
+ mention of a large project that uses Mercurial
|
| Jul 16, 2010 at 6:13 | history | edited | talljosh | CC BY-SA 2.5 |
added 211 characters in body
|
| Jul 16, 2010 at 6:08 | history | answered | talljosh | CC BY-SA 2.5 |