For AGS project managers/scripters: How to forbid concurrent access to files

[Monsieur OUXX]

Hi all,

I just opened a recent AGS project's folder and I noticed that the script files appear as plain text files. It seems that they don't contain any binary gibberish anymore.
Is it true, or is it only by chance?
If so, Does that mean they can finally be edited using an external editor, without breaking the project files???
That would be awesome!



Here are guidelines to implement locking of important binary files (e.g. main game file, aka *.agf) in the SVN versioning protocol.
If you implement this, it means that your collaborators will be able to edit-modify-merge script files (aka *.ash, and *.asc), but not binary files. We'll see later for refinements on "what specific binary files types should be locked" (if you don't want to lock image files a.k.a. *.png or *.bmp, for example).

As soon as I'll have experimented myself, I'll produce a small tutorial, specifically written for AGS project managers.



=============================== PRINCIPLE =================================

You'd still have to enforce that all files have the svn:needs-lock property; not just the existing ones but newly added ones as well.
"svn autoprops" can do that but then you have to make sure that each client has the correct autoprops configuration.
This can done in the config file for every client (miscellany: enable-auto-props = yes, auto-props: *=svn:needs-lock). Check the client setting by a pre-commit hook on the server rejecting non-locked checkins .

============== IMPLEMENTATION WITH A SCRIPT (DIFFICULTY: AVERAGE) ==============

this script must be run on every client's machine, but at least it's out-of-the-box.
See it here: http://www.orcaware.com/svn/wiki/Automatic_lock-modify-unlock

====== IMPLEMENTATION USING THE "TORTOISESVN" INTERFACE (DIFFICULTY: EASY) ======

See the great tutorial here: http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug-locking.html

=========================================================================

[Dave Gilbert]

ASC/ASH files have always been in plain text, I believe. My wife uses textpad all the time to edit those. It's the CRM files that are gibberish, so don't touch CRM files except with AGS gloves!

[Monsieur OUXX]

ASC/ASH files have always been in plain text, I believe. My wife uses textpad all the time to edit those. It's the CRM files that are gibberish, so don't touch CRM files except with AGS gloves!

Oh, alright!
Then any AGS game can be uploaded onto a CVS or a SVN.
I'm going to do that witht he kart game.
This thread can now be locked :-)

[Dave Gilbert]

Be verrry careful when doing that. Text files can be merged pretty easily, but ONLY commit the text files. Don't commit the whole project. CRM files or AGF files can not be merged, and it will screw everything up. So make sure only one person has control over the editor at a time. Not doing that leads to nothing but trouble.

[Monsieur OUXX]

I don't know anything about SVN or CVS administration, but is it possible to set up a server or repository to forbid by default the checking out of a file by several people at the same time? For example, user#2 couldn't check out the Game file until user#1 hasn't checked it back in yet. But both could work in parallel on source files and take advantage of text files conflict resolution.

If that sort of things exist, we could write a small tutorial about that (and even make the set of parameters available for download, if it's possible to export them), and add it to the Wiki: "How to develop AGS games with versioning tools".

updated first post

PS: I suggest this thread gets moved to the appropriate forum, since its contents have evolved to something new.

[Monsieur OUXX]

[double post]

[Calin Leafshade]

The way the editor maintains its source files currently is a clusterfuck and it essentially makes it impossible for teams to work on it. (Try Unity, it's much the same but slightly better).

Really, compiled data should be kept entirely separate from source files, probably in a second directory and not versioned at all.

So a Room would be composed of three files.

1. Background image,
2. Script,
3. Precompiled data.

Only items 1 and 2 need to be versioned, since item 3 is generated from them (and cached to allow quick recompiles).