Teamwork

Imagine a small developers team working on the same project. To avoid interfering one another and deleting someone else's work by an accident, the developers should somehow coordinate their actions. A good version control system (e.g., CVS, Perforce, ClearCase) would be a good aide for that. However, such systems either require significant time to be learnt or appear to be too expensive or all of the above.

ZSKSoft Synchronizer is great for working with smaller projects. It doesn't have the majority of the special features typical for such systems (branches and sticky label support, etc), therefore using it is so easily. No need to spend any extra time for studying; everything can be done using ZSync's default tools. The work model is clear and simple; therefore the final goal can be achieved quickly and with the minimal expenditures.

Each developer has an individual copy of the project, which he/she works with. There is also the public copy located on the server or on some computer's shared resource. For example:

Developer1                  Developer 2                Public
BACKUP                      BACKUP                     Source code
TEST                        TEST1
Source code                 TRASH
Object files                Source code
Executable Application      Object files
                            Executable Application

Each developer has his own copy of the source code. Besides that, in their copy of the project, the developers may create additional subfolders - for backup purposes, test data entry, and other purposes that not always can be clearly described. Often times, such subfolders appear for a one-minute need and then, just in case, they remain there forever: what if the need ever occurs again?

Along the work process, the developer changes something in his source files and then builds the application (at the same time, the development tools generates the object files - .dcu, .obj, etc.), and then tests how the completed application functions. Having made sure that it functions properly, the developer publishes his changes to the public folder. Simultaneously, this developer retrieves the other source files published by the other developers to the public folder; he/she needs these files to continue developing and compiling their own copy of the application.

The developer copies his files from his own folder to the public one, and otherwise - the others' files are copied from the public folder to the developer's personal folder. Besides, it happens that a number of developers can add changes to some files. For instance, that can be a module with public functions that doesn't have a specific owner - whoever needs new functionality, that one adds it; or the module consists of several parts that belong to different authors; or several owners own the module according to the currently popular methodology of the extreme programming. Such files can be copied in the both directions: if the developer has changed something in it, the file will have to be copied to the public folder; if someone else has changed the file (i.e. the file has changed in the public folder), the modified file will have to be copied to the developers' personal copy. Finally, if the file has changed in the both locations - the program will need to warn its users of that and do nothing until the developers figure the things out between one another.

The additional subfolders, object files, and completed applications do not get copied anywhere.

The figure displays a sample of a developer's ZSync screen. As you may see there, everything looks normally except for the following: the by-name categories were added with additional tabs (My, Others, Shared). With these tabs, user can control synchronization of his own and other people's files, as well as the files with shared ownership. And configure individual change flows for them:

The scheme configuration sample provided on the image once again demonstrates how the change flows look. Specifically - files related to the given developer (the My category) are copied from his personal folder to the public one, the other people's files are copied from the public folder to the personal one, and the shared files are copied in the both directions. The Off category includes files and folders that the developer created for his own purposes, and they are not to be published to the public location. Each developer just needs to select which files he considers his own, which ones are to be treated as shared, and which ones are to be ignored (the rest will automatically considered others') - once that all is completed, the team work development system is ready. If someone makes a mistake and appropriates himself someone else's file - once the changes are published, ZSync will immediately warn of that the other developer who has also added the same file to the My category.

Originally, the project sample included a few more subfolders. As the result, every time we had to make the note: "source files and/or contents of subfolders related to the project's public part..." The text appeared to be too large, and we had to delete the subfolders from the example, having left only the source files. But, of course, ZSync synchronizes projects with any number of nested folders just as easy - just don't add them to the Off category.

Each of the developers builds his own copy of the application executable files, but that's the working copy, which includes the modules that are not yet published, i.e. those that have not been tested by the developer completely. To be able to build the completed application at any time, you may find it useful to have another copy of the project maintained specially for compiling the stable version; using this separate scheme, you will add it with files from the public copy. The copy for the final building can be kept on the developer's computer who is in charge for that or on the shared resource to let any developer compile the final application. Of course, you can compile the final application right from the public copy; this way's shortages are aesthetic only: the public copy gets overwhelmed with object files; they should be ignored during backup, etc. Generally, that's a matter of taste.

To ensure the smoothly, efficiently, no blunder teamwork, the main thing is not the software you use but the organization of the process. In other words, you should first of all try to properly distribute the work among your developers. That is not such an easy deal, as it may seem at the first sight: you should take into account that developers specializing in particular technologies (e.g., data processing, reports, communication, etc.) output greater efficiency. On the other hand, workmen operating a number of technologies simultaneously possess a wider mental outlook. There are also other factors that are hard to be described in brief. ZSync allows you to easily distribute the modules; so easy to be exact that it lets the process run on its own. But do not let the ease deceive you. Do not forget to apply at least the minimum efforts to organize your work properly.