Generally I agree with Chad's choice to use git as FileSystem behind an
Asset Control System as it is fast, reliable and deals rather well with
binary files. Gits storage mechanism is very efficient at least.
Efficient handling of binary files is a main point, but as it has already
been pointed out, there are other important features as well. I picked
subversion because of the following reasons over git ( and back then, I had
the choice ):
1. SVN is very well known ( to me )
- Git will cost a lot of research and probably lot's of custom
programming
2. SVN runs perfectly on linux and windows, whereas windows also
offers a nice explorer integration
- Unfortunately, I need to support windows as well. As maya runs on
windows and osx in addition to linux, an asset management
system would need
to address all platforms
- Some of gits advanced features appar to rely on characteristics of a
linux file system that are impossible to get on windows (
hardlinks could be
simulated with junctions, this has been mentioned in one of the previous
posts as well )
3. SVN has a python module which is known to work
- git has one as well, but is it mature ?
- http://gitorious.org/projects/git-python/
4. File Locking
1. Native and fast in svn
2. git would need that to be handled by some service controlled by the
asset management system I suppose, so it's custom development here
5. Partial Checkout/ Partial Update
- Its important that people may checkout/update only the portion of the
repository they actually work ( and have a lock on ) - in my case it's
individual files most of the time.
- Its possible to retrieve only a single file for working
- In git apparently one has to get the whole repository ( which can
be prohibitive ) , but perhaps some special workarounds exist
- Also I agree that the reason I need this might heavily be based on
my local->server paradigm - other more 'gitty' paradigms might
not need this
at all - but yet I cannot imagine how branch based workflows
might work, and
how branch merging would perform without conflicts.
6. ( ACLs )
- At least available in svn, but currently not used in my production
as there is just no need
- Could be useful in case of distributed productions
7. Distributed Productions
- Due to the centralized nature of svn it would naturally be capable
of serving many locations, but without further adjustements it
would be too
slow for everyone not connected with at least 100 MBit
- SVN Mirroring could be setup, but this would require a custom
solution for a lock synchronization as well
- git might handle that part more efficiently due to its network
optimizations and it's distributed nature ( if merging would work safely )
- In general, things get easier for both svn and git if one can assign
logical portions of the production to one location that must
just be pulled
or updated by the main company from time to time - thus
different locations
completely own portions of the project, making individual file locks
unnecessary.
My conclusion back was and still is that one will get good results faster if
relying on svn, but one apparently has to take some caveats which cannot
easily be workarounded.
(NOTE: SVK apparantly does it better here and there, it uses svn as backend
and goes deep into the api so it actually workarounds the 'file duplication'
when checking out files ).
*
SVN and Binary files*
Yes, it is an issue. Every file is held twice in the repository checkout -
the server side will thus contain twice as much information, updating files
is slower as at least two possibly large files have to be handled.
Also I noticed that the delta algorithm appears not to be in effect with
binary files or usually has no visible effect on files over a certain size.
To me it felt as if it would always store PSD files ( for instance ) as a
full copy, even though you literally just changed one pixel.
Transfer speed of binary files is rather slow - I get between 5-7 MB
upstream. Updating large binary files is not fast either - there is a server
side bottleneck due to the immense overhead imposed by the delta's. The more
revisions have to be retrieved, so worse it is.
A complete checkout of a repository with large binrary files is quite slow
and far away from what I would like to have.
Git would probably score here ( at least it would be faster ).
In practice, checkout's are much slower than updates, fortunately you update
most of the time.
Importing binary files is rather fast as SVN doesn't have to do much more
than compressing it, so it is not so much of a problem.
For me, the biggest caveat truly is the waste of diskspace on the server -
the slow binary performance only really shows when committing 100MB+ -
everything else is feels acceptable on todays hardware.
*Asset Management and Branching*
I don't really know how branches would properly be implemented in an asset
management system and plenty of binary files. Merging algorithms will fail
on binaries ( and complex asciis like ma ), but if specialized, it could
work well ( see .gto format ).
Having different versions/variations of the same file around is a good thing
though, but currently I catch that through the folder structure and
conventions that are enforced by the system. SVN does not know about it
though.
*Finally ...*
I absolutely think that git could do it if one writes some new porcelain for
it that enforces the constraints of an asset management system, but from
what I see it will be a great effort ( good things never come easy though !
).
I will try to switch my own development to git as far as possible, still
piping changes to svn in the end ( using git-svn ). This way I should learn
many interesting things about it that might help me to contribute some more
useful information to this topic in future.
--~--~---------~--~----~------------~-------~--~----~
Yours,
Maya-Python Club Team.
-~----------~----~----~----~------~----~------~--~---
