I've been playing around with git and AGS today, and so far I find no reason it shouldn't work, however, due to AGS-restrictions, we need to lay down some rules and conventions to get a seamless multi-user collaboration.

What's so cool about git is how you can make separate branches of the project, making a branch a separate environment a user can toy around in, not affecting the master build. However, any user can work in any branch, including the master branch, and this opens a world of potential problems.

Considering we're going for the open source route, we'll want to give permission to anyone who has something to offer, but if we were to stumble upon the common internet troll or someone had an accident, suddenly everything would on sourceforge would be wiped away. Removing all of the hard work anyone were currently doing, and also the latest edition of the master build, which is what everyone should always be working on at all times as a foundation.

Now I assume Robert has the foresight to back up the latest edition on his local computer, but this would leave everyone in his power, having to sit idly until the master build gets loaded back up again.

Googling some common practices gave me a rough idea on how this could be fixed as fluently as possibly.

- Have a local master build with read only permission, only admin can edit it.
- Have a remote master build with write access to developers. Sourceforge supports having multiple git projects in one sourceforge project, so this shouldn't be problem.

Now how this would work, is that everyone is free to work on the remote build, and if anything majorly cocks up, we're at any time free to extract the local build and start over at a relatively updated build. Whenever anyone is finished implementing something to the remote master, admin can check the changes, give feedback if he doesn't the implementation, or if he thinks it's good, put in in the local master build, finalizing it.

That would take care of one problem, however we'll need to discuss branches next, as multiple users working on one project, writing code and what not, could give interesting conflicts when they work on the same files, at the same time. git is built to work great with files that can be represented in text, which is what you normally do under a pure programming project, however AGS compresses and archive resources on the go, instead of on compile.
The idea I've come up with to reduce this problem down to the most minimal, is to utilize branches, a ton of 'em, let's use the recently implemented options menu as an example.

The Options menu had several issues, it didn't show up on the title screen, it had functions we don't want or desire on the title screen, it had no GUI implementation to be called in-game, some of the functions in it didn't even work.
Mapping out these issues and reducing them as tasks(ticket system in sourceforge, ka-ching!) could allow multiple users to work on the same stuff and not override each other. Say we make a branch of the remote master build, and call it "optionsmenu", every task that is associated with options menu could be a sub-branch of the branch "options-menu".
When a task would be completed, the assigned worker can ask for some feedback, from the others working on the same master branch, and if it's good, merge it with the master branch. When all sub-branches of the main branch is done, and the of course if the main branch is running and functional, it is ready to be merged with the remote master build. From there the admin would again merge the local master with the remote master. And finally overwrite the remote master with the data from the local master, to enforce that is the most updated and current version people are working on.

Things to be aware of:
- I'm still not sure of how a git system would affect sprites and other stuff that is made into a binary file the moment they are added to the project. One solution would be to just ignore that stuff on git, and implement it like we did before.
- Anyone that would wish to contribute should show to some results they can contribute with, let's avoid a random person entering the project and wiping everything out as much as possible.
- http://www.adventuregamestudio.co.uk/wi ... ce_Control
- git can be tedious if you're new to it, but the more people that is working on one project, the more it's worth it. Especially on a project like this where people live so far away from each other.

I've attached a diagram that I hope explains visually what I'm trying to convey. I know all of this may sound extremely tedious and micro-managemently, but I believe it's worth the effort, as it can give a very streamlined work flow and always access to the latest build.

PS: Sorry for the wall of text

The attachement was kinda huge, and destroyed the text formatting, here's a link instead, clicky clicky https://www.dropbox.com/s/o3zqtj9p99wpz ... iagram.jpg

I was totally thinking about sprites/character files while reading that. Those are definitely stored in a single file and have to be modified via the AGS editor. I like the idea of creating a task completion list and the shared/main versioning system you've described. I'll need to look into branching a but more and see if there is a way to merge the RO master with the RW master.

Also, I have the current version in triple-backup

_________________
Robert

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
"What good is knowledge and wisdom if you can't use it?" - Erasmus

git supports multiple remotes in one repository so it sholdn't be that much of a problem, say you have a local git, and clone both the readonly and the readandwrite remotes into the folder of the local git. It will show up in the git listings as two separate projects. The syntax for merging branches is "git merge optionsbranch", where it will extract the branch and it's content and literally merge it with what's in the folder you're currently in. And it seems to be the same way for remotes, "git merge readwriteremote".

I haven't tested it myself yet, but readings like http://saintgimp.org/2013/01/22/merging ... e-history/ suggests it should be fairly simple. I'll probably check it out more later if you haven't already. Right now I need sleep.

Do you use any special tools for git? Or just the bash line? I was experimenting with how to work multiple masters, but it seemed way too convoluted with just the standard git tools alone. So now I'm trying to find any decent git management tools.

I was using the Windows version of GitHub, but it doesn't work well with the SourceForge repo. I've been doing everything for the SourceForge repo from bash.

_________________
Robert

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
"What good is knowledge and wisdom if you can't use it?" - Erasmus