AVS versus Continuus

1/ Both are configuration management softwares, using development tasks as transactional container for repository updates.
2/ Continuus is quite expensive while AVS is free.
3/ Continuus is a complex software. Learning curve is long, and training is mandatory for build manager and administrator. On its side, AVS is quite simple, and works immediately once installed: not external components needs to be configured.
4/ AVS embeds the change request database, which helps creating update template, called "reconfigure folder", in Synergy language: when creating a task based template, all the tasks are shown in a tree table, showing the change requests at the first level, and the attached tasks underneath. Open tasks, which cannot be used for the template since they are not yet closed, are also shown in italic. Hence, if the build manager chooses tasks from a change request in which there are tasks still opened, he can see it at once, and will not need compiling to discover configuration inconsistencies. He can create his template on a change request selection approach, rather than task, which is more appropriate to create the target release, while still controlling the development tasks he really integrates.
5/ Since AVS embeds its change request database, users need not have two interfaces to manage their files and their change requests: all the features are available in a single client application.
6/ AVS users do not need to change the profile they use to get access to restricted features: either they have the access and the feature is enabled, either they do not have the access, and the feature is either hidden or disabled.

AVS versus SVN

1/ Both are free, SVN deals with version management, not configuration management
2/ SVN relies on a confusing revision number: if two persons work on different branches, their revision number change even with other developer's commit.
3/ Integration between SVN and existing bug tracking softwares are not efficient: at most, you get a tool in which you specify a bug id during commit, which will then be closed at the same time. But what happen if you put a wrong id ? You may associate files from a project to an open bug on another project !! Moreover, since this integration leads to a system with 2 databases, what happens if one fails during commit ? No 2-phase commit, so the rollback is not done, and you get a scrambled system. AVS integrates the file control system and the bug tracking in the same database.
4/ With SVN, you get ".svn" folders everywhere on your local repository, making it hard to clean if you want to make a backup. AVS uses an embedded SQL database on both client and server, without interfering with your local repository.
5/ With SVN, conflicts are discovered much too late, on commit, when the work is done: two persons may do the same changes at the same time without knowing it. Worse, two persons may do very conflicting changes without knowing it. With AVS, you "check-out" a file to get it working and owned. If not the last version, you need to grant a parallel version creation: a merge will be needed in the future, but at least, you know about the conflict before you start working. In such case, you can get in touch with the other person working on the file to evaluate the merge difficulties to come and estimate whether the parallel version is a good thing to do or waiting would be wiser.
6/ As a workaround the conflicts, SVN uses a lock mechanism which prevents everyone to commit changes on a file if you have set the lock. In any case, the conflict is still discovered lately. Parallel versioning is more efficient since everyone can work on the same file at the same time, knowing about the conflict before they start working.
7/ AVS uses development tasks to group working files: when checking-out a file, you know the reason why, so you associate the file with the right task at the right time. When checking-in the task, all associated files are checked-in: you may work on many tasks without fearing to check-in the wrong files. With SVN, if you want to work on many independant tasks, you would need to make many commits. But if you modify a lot of files on each task, you get a lot of chance to commit the wrong files since they have no grouping container. With AVS, you still can check-in the file without checking-in the task.
8/ SVN does not allow easy integration: suppose you want to deliver a version of your software excluding a few bug fixes because not tested yet, it is a very hard task to achieve. With AVS, you create update templates, containing a list of development tasks. When updating your local repository, you must first select a template. So if you need to exclude some fixes, you just need to remove the corresponding tasks from the template.
9/ SVN server uses a non relational database, BerkeleyDB, which does not help migration to another SCM software.