Mercurial with Largefiles: Why it is not a solution for game development

Re:Mercurial with Largefiles: Why it is not a solution for g... by pjc50 on Sunday December 03, 2017 @03:00PM (#15839208)

Important point here is that if:

- you have lots of large files which are not amenable to diff and change frequently;

- everyone is working within the same company, and usually on the same network;

then a DVCS is unhelpful because you have to spend the disk cost for the repositories on every machine having a full copy of everything that's ever been checked in, regardless of whether they need it or not.

Many games are tens of gigabytes when shipped. It's easy to imagine a process which accumulated hundreds of megabytes of asset changes every single day over a multi-year development process. Then you can imagine having to have expensive terabyte SSDs just to work on it with all your tools.

I'm actually looking at this problem at work for possibly converting a large repository from svn which is a decade old and merely tens of gigabytes. Frankly svn handles it just fine so I'm going to defer the problem until I absolutely have to migrate.

[ Parent | on HN ]

Re:Mercurial with Largefiles: Why it is not a solution for g... by Negitivefrags on Sunday December 03, 2017 @03:59PM (#15839558)

As a point of reference, here are some sizes for the repos of the game I work on which has been developed over around 11 years.

120 GB for the game data repo. This is the repo for the source and art that actually ships.

2.5 TB for the raw art repo. This is where the pre-export raw files go.

Obviously it would be impractical to require that the artists all have the entire repo. We use SVN.

[ Parent | on HN ]

Re:Mercurial with Largefiles: Why it is not a solution for g... by merb on Sunday December 03, 2017 @04:20PM (#15839656)

> which has been developed over around 11 years.

are there that many games which have a lifetime of over 11 years? I only know about one...

[ Parent | on HN ]

Re:Mercurial with Largefiles: Why it is not a solution for g... by Negitivefrags on Sunday December 03, 2017 @04:30PM (#15839703)

There are many. Online games have very long lifetimes.

Think of League of Legends, Team Fortress 2, EVE online, World of Warcraft. There are hundreds more smaller games.

[ Parent | on HN ]

Re:Mercurial with Largefiles: Why it is not a solution for g... by merb on Sunday December 03, 2017 @04:58PM (#15839851)

well lifetime = time where stuff is still under development. LoL = not more than 11 years old (heck it's not even 10 years old) TF2 had it's 10th anniversary this year. which means eve online, WoW and runescape still get patches/updates/etc.

as said there aren't that many games that have a lifespan of over 11 years.

[ Parent | on HN ]

Re:Mercurial with Largefiles: Why it is not a solution for g... by islanderfun on Sunday December 03, 2017 @05:53PM (#15840135)

You've been given plenty of examples showing it's been done. What's the point you're trying to reach?

[ Parent | on HN ]

Re:Mercurial with Largefiles: Why it is not a solution for g... by Negitivefrags on Sunday December 03, 2017 @05:02PM (#15839883)

League of Legends started development in 2006 and TF2 started development in 1998 or 2005 depending on if you start counting from the redesign or not.

There are so many games that have this long a lifespan.

[ Parent | on HN ]

Re:Mercurial with Largefiles: Why it is not a solution for g... by ngold on Sunday December 03, 2017 @04:51PM (#15839814)

I still play CS 1.6 which is getting close to 20 years old.

[ Parent | on HN ]

Re:Mercurial with Largefiles: Why it is not a solution for g... by merb on Sunday December 03, 2017 @04:58PM (#15839855)

cs 1.6 is not under active development.

[ Parent | on HN ]

Re:Mercurial with Largefiles: Why it is not a solution for g... by wolco on Sunday December 03, 2017 @10:12PM (#15841221)

yearly sports games like baseball mogul change yearly but same base

[ Parent | on HN ]

Re:Mercurial with Largefiles: Why it is not a solution for g... by maccard on Sunday December 03, 2017 @05:14PM (#15839947)

Someone else’s mentionec the size of their repo on a game that’s 11 years old. Last time I checked on an unreleased project, in development for about 4 years at this stage, we have 200GB of source code and binaries checked into perforce for normal usage, and about 800GB of source assets (audio, models, textures). We probably 150 changes a day, and about half of them are to art content, the other half to code. There’s a lot of churn, and this is on a “small” AAA project (probably about 100 people total).

[ Parent | on HN ]