0

So I have this dilemma I'm trying to solve. I am an indie game developer working on 6-7 client projects at any given time with the Unity game engine. The problem I'm experiencing is keeping my shared-code synced between the projects - my current solution is very "manual" and time consuming (and error prone when I forget to update everything). I started looking into SVN externals as a solution, but there's one problem. The Unity game engine uses *.meta files to maintain data for how the files in question are used within each game.

As a quick example - here is a sample folder structure:

Project 1:

  • ROOT
  • ROOT/Assets
  • ROOT/Assets/SharedCode
  • ROOT/Assets/SharedCode/SharedScript.cs
  • ROOT/Assets/SharedCode/SharedScript.meta

Project 2:

  • ROOT
  • ROOT/Assets
  • ROOT/Assets/SharedCode
  • ROOT/Assets/SharedCode/SharedScript.cs
  • ROOT/Assets/SharedCode/SharedScript.meta

The obvious/immediate solution is to just make my "SharedCode" folder an SVN external. The issue that arises is that the SharedScript.cs file should be identical on both projects, but the SharedScript.meta file is project specific and auto-generated by the game engine (so I can't say, store all my meta files in a single folder somewhere external to the "SharedCode" folder).

There are hundreds of these files, so I'd love a solution that doesn't involve treating each "shared" file as an SVN external unto itself.

My current ugly solution is to keep the whole project tree in SVN - and I have a sub-folder that is a GIT repo which ignores the .meta files. It's pretty ugly though, and I frequently commit/update the main project and forget to commit/push/pull the git "library" project.

Any suggestions would be greatly appreciated!

Rune Vejen Petersen
  • 3,201
  • 2
  • 30
  • 46
user1348575
  • 1
  • 1

2 Answers2

4

Why not just use one versioning system for the code and one for the assets of the unity project. Then use svn:externals for the code that needs to be shared between projects.

You could ignore the meta files in your project and use git to version the meta files.

ForceMagic
  • 6,230
  • 12
  • 66
  • 88
Kristian
  • 41
  • 2
1

Why not make your "SharedCode" folder an SVN external - but without the "SharedScript.meta" file (and any other files that are project specific/auto-generated).

Now have the SharedCode.csproj point to a non-existent file, "$(SolutionDir)/<(blah)/SharedScript.meta". You can simply hand-edit the csproj to do this. Note that all your solutions MUST now generate this meta file to this relative path.

Now when you add this csproj to the solution of your choice you'll need to set up the project dependencies so that "SharedScript.meta" file is generated before your "SharedCode" project is built. Now there shouldn't be any issues.

Hope that helps!

Ani
  • 10,826
  • 3
  • 27
  • 46
  • I don't have control over the generation or usage of .meta files - the Unity game engine handles all of that automatically. I wish I could control them manually, I'd just have the meta files generated in a mirrored path (like Assets/ for actual scripts and AssetsMetadata/ for the *.meta files). The solution I've come up with so far is to use an SVN external as well as a junction. So the external would look like... SVNROOT/Externals/SharedCodeExternalRepo and then I would junction that out to... SVNROOT/Assets/SharedCodeExternalRepo – user1348575 Jun 03 '12 at 17:08
  • Doesn't matter - the solution provided above should still work. – Ani Jun 03 '12 at 20:25
  • Agreed... it's generally bad practice to store auto-generated files in version control... they can wreck havoc with cross-platform builds and version control merges. – Peter Bratton Jun 04 '12 at 14:11
  • In this case we just don't have a choice. The .csproj files are also auto generated by the engine, but aren't actually used for anything other than making it easier for us to edit scripts in an IDE. The *.meta files exist solely to be version controlled; if there was a way around having to use them we'd jump on it immediately. The important bit is that the .csproj is completely irrelevant though, it's never actually compiled and any manual editing of it would A: Be overwritten immediately by the engine, and B: Would have no impact on how the engine actually used the code anyway. – user1348575 Jun 04 '12 at 16:06
  • It's a problem very specific to the Unity game engine, and it's beginning to look like there's no good solution to it. Thanks for all the suggestions anyway, I really appreciate it! – user1348575 Jun 04 '12 at 16:07