2
\$\begingroup\$

We use svn at work, but the repository is getting pretty large, so checkout times are long, as is update when artists batch process all assets.

The problem is that we also store work in progress, prototypes, small tests, legacy stuff and other 'junk'.

Now theoretically, some of it can remain local and uncommitted until it is ready to be included, and a lot could be deleted and cleaned, but that's irrelevant for this question.

Imagine a new asset, a level for example. The artists and designers want it shared and in version control so several of them can work on it, but everybody else does not need it.

Obviously multiple repositories are an answer: one for artists, one for programmers and one for the main project (for testers, building demo versions and finally the main product), which would be really tight and minimal, with everything needed for the game and no more. And then when an asset or some code is 'mature', it can be copied into the main project and committed.

Here's my questions: is it possible to have multiple repositories overlapping so that the artists can have one with everything they need, likewise for programmers. And only when ready commit the same file into the project repository too? This would eliminate bloat of having multiple copies of files and avoid conflicts between repositories.

I know old svn versions stored invisible files in all directories, so it would be impossible, but new svn versions store all meta data in the root directory right? So it might be possible.

I imaging the answer will be 'impossible', or even if possible, yuck! I suppose it would cause all kinds of headaches. Like checking it out in one repository would mean it would need to be committed/deleted in another.

But how about making a svn_commit script, that overrides svn commit with additional checks and housekeeping?

This is just a thought experiment really. I was wondering if anyone has ever done anything like this, and what would be the issues to be resolved. Cheers

Improve this question
\$\endgroup\$
9
  • \$\begingroup\$ Can't you keep one repository and the developers just update the directory they're working on? You can perform an SVN Update on a single directory within a repository. I'm sure the developers don't need to update the art work-in-progress directories when they just care about the source code directories. \$\endgroup\$ – MichaelHouse♦ Apr 17 '13 at 22:37
  • \$\begingroup\$ So you mean do what I was talking about at the directory level, not the file level? But when migrating an asset from artists directory to main asset directory, you would lose version history, right? \$\endgroup\$ – DaleyPaley Apr 17 '13 at 22:45
  • \$\begingroup\$ Also, the artists' directory would have to be way up in the hierarchy, because people need to update from near the root, otherwise they would have to update from many separate directories to avoid it. This it the same as just having multiple, separate repositories. \$\endgroup\$ – DaleyPaley Apr 17 '13 at 22:47
  • \$\begingroup\$ What you're describing is ideally suited for a branch-friendly version control system like git. Are you particularly constrained to SVN? \$\endgroup\$ – Mokosha Apr 17 '13 at 22:48
  • 1
    \$\begingroup\$ I was suggesting that maintaining those scripts would be easier than maintaining multiple repositories. Further, you could have a developer script, artist script, etc. Each of those would also be stored in the repository, and could be updated first, then run. \$\endgroup\$ – MichaelHouse♦ Apr 17 '13 at 23:04
4
\$\begingroup\$

I think (from your description), that svn externals will be correct answer:

  • You have not copy object from repo to repo - you have single object, which is linked to and can be used from different targets
  • "Thin" final repositories can be just any (only) collection of externals to the repositories, which holds data: you have additional flexibility in building needed trees and managing access-rights
Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ Yes, this looks like the right answer. I didn't know about externals. But it does seem that there are some limitations and gotchas to be aware of. Thanks \$\endgroup\$ – DaleyPaley Apr 18 '13 at 0:11
  • 1
    \$\begingroup\$ I don't recommend using svn externals for this situation. They are a solution when a project has external read-only dependencies, but for other cases it has too many problems with branching/tagging and committing. \$\endgroup\$ – msell Apr 18 '13 at 5:54
6
\$\begingroup\$

https://stackoverflow.com/questions/50945/can-you-do-a-partial-checkout-with-subversion

Specifically, not everybody has to check out the whole tree. TortoiseSVN has a pretty user-friendly GUI for this.

You can tell people to not check out certain folders (for example, programmers could skip the art source folder).

Depending on your exact directory structure, this won't require any changes on your part.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ Thanks for the link, I will have to look into that further. As for TortoiseSVN, the problem is that at work, some people use windows, but many others use macs. It would be better to have a unified solution. \$\endgroup\$ – DaleyPaley Apr 17 '13 at 23:54
  • \$\begingroup\$ @DaleyPaley TortoiseSVN is just a pretty GUI. You can checkout just a subdirectory simply by doing svn checkout to that specific subdirectory. In fact, you can set branches for each subdirectory separately, so you can for instance, keep branches for source files, but just a single repository for documentation and art. \$\endgroup\$ – Panda Pajama Apr 18 '13 at 1:17
  • 1
    \$\begingroup\$ @DaleyPaley The link in the answer has instructions on doing it from the command-line as well. I think this answer solves your problem (long checkout/update times) with the least effort. You can just use svn update --set-depth=exclude <foldername> on an existing working copy for the folders you don't care about. \$\endgroup\$ – msell Apr 18 '13 at 5:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.