Asset Management with ionForge Evolution® Part 2
by Lucas Heneks

Hello again! The response for my first article was excellent for such an "unsexy" topic. Thanks for the questions and comments. For the second installment, I'll start off by answering some questions and concerns.

When I wrote the first article, ionForge offered a free two user license. Between the times I submitted it and it was put up, we moved to a free single user license.

I do work for ionForge, so I am admittedly biased, but rightfully so :).

Asset Management is similar to source control, except that it encompasses all digital assets, such as art files and documents. This is essential to any project, and when you have a project like a game with so many non-code assets, it becomes almost criminal not to use a good asset management system.

The last concern I want to address leads into big topic, but I will make an attempt at a short answer. Feel free to skip this paragraph and the next, because it won't affect your understanding of the article in any way. Why is Evolution Better than CVS? Or Subversion? Or …. The answer to these will often be "Do you want the whole list?" But of course it depends on your needs. If you need Linux support right now, Evolution is out. If you want an intuitive GUI, CVS is out. If you hate shell integrations, Subversion is out. Of course, there are plenty of other competitors, but since we are focusing the indie market, I'm only bringing up our low cost competitors. If you are on Windows, and like a nice clean GUI, then there is at least one thing that Evolution does better than the others. And that is branching.

What is this branching stuff anyways? If you do not have a lot of experience with software in Evolution's category (referred to as SCM, or Software Configuration Management), you may not know what branching is. Branching is a complex topic in SCM, but the most common explanation of branching is that it is what you do when you need to work on two distinct copies of the code at the same time. For example, there is your "Stable" code upon which you only want to apply emergency fixes, and your "Development" code upon which you work for your next stable release. You may also want to branch when you start development of version 2 of your product. There are plenty of other uses for branches, but we'll leave that to a later article. Stick around for more reasons why Evolution is better than the others.

Now on with part two.

Background

Ok, so I assume that you have finished part one and have an installed Evolution server and some clients (at least one). If not, what are you waiting for, a link or something? I will also assume that you plan to use it with a team sometime in the future and that you have already imported some files.

One thing I didn't go over last time is what exactly asset management is. Oops. For those not familiar with asset management, it includes versioning of files, meaning that each time a file is submitted to the system, its state is saved and can be retrieved later should the need arise. This means that any version of any file in your project can be retrieved. It also helps with collaboration, as there is one central place to retrieve any of your project's files and to be sure that you are getting the latest ones. If you don't have exposure to it yet, you will when you get into the industry, regardless of what your position is. Artists, programmers, composers - everyone has to use it in a professional project, so if you are an indie or hobbyist, you might as well get used to it now.

Locks aka The Real Part Two

In asset management, much like an operating system, there is the concept of a lock. A lock prevents other users from changing the server state of a file unless they too acquire a lock on that file. When a user requests a file, he is actually requesting a lock on the server state of that file. The server (in Evolution's case) can also serve the file at that point. In Evolution, there is more than one type of lock. The first, and Evolution's default, is the exclusive lock.

Exclusive locks allow only one person at a time to lock a file. This means that if one person gets an exclusive lock on a file, anyone else who wants it must wait until the lock is released. Exclusive locks are considered unworkable by some, but they do have many benefits. You will never have to merge for one (more about that later). You will never have two people doing the same work on the same file. We use them intermixed with the next type of lock.

The second and most common lock in other systems is called the shared lock. A shared lock allows multiple users to get a lock on a file at the same time. This means that two users are working on the same file at once. Eventually, one will check it back in and move merrily along. Then the other checks it in. The second user will have to manually step through the file and reconcile the differences between the server's (the first user's) copy and his own. This is called merging. We try to prevent as much merging as possible with our product because we have all been through some painful merges. But some people prefer to work this way, so we support it fully in our product.

The third type of lock - and as far as I know, a feature unique to Evolution - is called a deferred lock. When one user acquires an exclusive lock and another user comes along and requests the same file, he can request a deferred lock. What this does is start up a server managed queue of requests for that file. As each user requests the file, they are put in line for that file, and at the same time the current owner is sent an email that says nicely to please hurry up. When the current owner checks the file back in, the system locks the file for the next person in the queue and sends them an email to let them know that it is ready for them.

Bigger Picture with Locks

So we give you the flexibility to do whatever you like. But what does this get for you? In general asset management, there are two types of basic workflow. One is edit-merge-commit, and the other is check-in-checkout. Exclusive locks directly correlate to check-in-checkout. Shared locks can be used to make a checkout-edit-merge-commit(check-in) workflow, which is basically the same. So Evolution allows teams to work however they want, including a hybrid of the two most common practices.

Best Practice Tip

Starting this time, I will try to include some best practice tips at the end of each article (thanks for the idea Cam).

In regards to locking the best practice for small teams (assuming that no one is going to suddenly disappear) is to force exclusive locks. This can be done from the Server Manager with Evolution. The reason is that even a single large merge takes too much time for a team member. In a small team, you have so few resources that a merge is far more costly than just working on something else. For large teams, there may be no way around allowing shared locks, but you will save tons of merge time if you encourage exclusive locks wherever possible. Even large teams should try to only use shared locks in areas of code under heavy modification.

Ok, so I have addressed the small and the large, what about the medium? That's where flexibility comes in. You will need to be able to choose your best workflow, whatever that may be. My recommendation is to enforce exclusive locks as long as you can, and when you find that programmers are spending too much time waiting for a key file, open the system up to shared locks. Only when you team is spending lots of time waiting on files should you force shared locks.

That's all this time, join me next time for part 3, tentatively titled "Components, Projects and Revisioning."

About the Author

Lucas Heneks is a Software Engineer for ionForge. Say hello to his little friend.

The views and opinions expressed here do not reflect those of ionForge.

Discuss this article in the forums

Date this article was posted to GameDev.net: 5/9/2005
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
Featured Articles