Collaboration in the past
Today let me make a journey into the past and tell about how our collaboration workflow look like before we have switched to git.
When we just started we have used a forum software set up in a local network. It was our test workflow, that’s why all titles on screenshots are in Russian.
The forum was split into categories and every thread represents a scene or a library element (we called such elements “tasks”). Also there were threads containing documentation about project and used software.
When a person wanted to work on particular task, he just downloading the archive containing task files from the last message of the task thread. Then he had to check if some library elements used in task have new versions and update them. After finishing work, contributor archiving the resulting task files and uploading them to the forum. Such usage of forum software for keeping project files had obvious advantages:
- Easy to use for contributor
- Version control implemented through forum messages
- It is easy to discuss the changes
That approach works very well, especially because the project was structured as relatively independent modules – scenes (thanks to storyboard). But during the 3 months of work following disadvantages were revealed:
- Every user should update all files related to his current task by hand
- Uploading a set of files is a time consuming process
- There is no mechanism of tracking changes in working copy
- Non effective storage of file versions
- Lot of work needed to construct full working tree of project
At that time every scene have been rendered by hand and then inserted into the montage. We started to realize what for such huge (and quite ambitious) project we need something what will eliminate such routine tasks. Then we come to idea of using “make” for this. Digging deeper into the problem it’s become clear, what the best way to implement project build system is to make a solid project tree. That made the future use of forum software for storage the project data impossible.
Then there was a deep research of different version control systems (svn, bzr, mercurial, git) and finally we are stayed with git. But that’s another story.