Telelogic SYNERGY
From Wikipedia, the free encyclopedia
 |
This article or section is written like an advertisement. Please help rewrite this article from a neutral point of view per Wikipedia policy. Mark blatant advertising for speedy deletion with {{db-spam}}. (help, talk) |
 |
The neutrality and factual accuracy of this article are disputed. Please see the relevant discussion on the talk page. |
 |
Telelogic SYNERGY is a software tool for revision control (configuration management, SCM etc) of source code and other software development assets. It was formerly known as Continuus/CM. Continuus was purchased by Telelogic in 2000. Telelogic continues to develop and market SYNERGY.
[edit] Task-Based CM
The Task-based approach used in SYNERGY allows teams to create work tasks or assignments that may be linked to defects or change requests. When developers work on tasks, impacted objects are automatically linked to the task and delivered into the process with it. Since configurations and releases can be created by selecting the tasks to include, SYNERGY can provide complete round-trip traceablity: how change requests were implemented and what changes are included in a build. Traceability can be viewed to original requirements for DO-178B initiatives.
[edit] Transparent CM
SYNERGY's ActiveCM approach provided a fresher way of looking at configuration management, by running the tool in the background and automatically tracking edits, additions, deletions or renames in the file system. This provided a more usable interface for non-developers, critical for corporate roll-out of initiatives such as CMM or CMMI.
[edit] MultiSite
Another strength of SYNERGY is its MultiSite extension, DCM. Multiple sites can exchange source code, tasks, change requests and even process definitions. The elements that are exchanged can be defined by the GUI and filtered so only the desired information is sent to the other sites, for security or bandwidth reasons.
[edit] Process support
SYNERGY comes with a set of out-of-the-box models for common processes. This helps fast set-up of development environments such as agile software development.
[edit] Anti-Advertisements (Critical Analysis and Review)
NOTE: The author generally prefers a bad-news first presentation in any review. It's like putting the warning labels out front where they will do the most good. There are other places where glowing exhortation can be had, so first the warts, then the gems.
[edit] Procedural Issues
It seems fairly clear that most of the original entry was generated as marketing. This section is an attempted response or cure for the unremitting up-speak above. The observations below are based on one (1) person's first-hand use and analysis of version Synergy 6.4, which is reasonably current as of this writing, this analysis may therefore contain mention of specific issues that no longer exist. Others are encouraged to refine or refute the nature or severity of these cited issues or amend new issues.
[edit] Our Way or the Highway
Synergy actively resists common developer actions. That is, by policy or design, the system requires the developer to follow some very restrictive paradigms. Some management may feel that this is a feature, not a bug, but your developers may not agree. Many of these restrictive paradigms then fail to deliver the potential benefit that the restrictions seem designed to provide. The worst offenders in this category follow.
[edit] Task-Based Development missing Task Dependency Support
The development is "task based", which may at first seem to imply change sets in the classic sense. Indeed the directions strongly imply that tasks are change sets. In practice tasks tend to lack the expected granularity of a change set, unless the developer takes undue care. There seems to be no meaningful way to assert that a particular task is dependent on any non-zero set of prior tasks. There is a partial attempt to mitigate this as a task can have an attribute that says it *fixes* a single prior task. That is, the only available dependency is (e.g.) Task#5 fixes Task#2. If Task#5 is dependent on changes made in (e.g.)Task#3 it remains possible, or even probable, that at build time individual developers or builders will end up with a failed build because they didn't chose to "add Task#3 to their folder".
[edit] This is Not Your English (Redefining Common Words)
The interface terminology subverts common English usage. Consider "folder". A Synergy "folder" is a collection of tasks in the database which exist only as a template. A folder, like every other Synergy conceptual atom, has a name and a number. Folders are expressed into the Workarea by name only. The individual workstation (or perhaps system-level login account) can only support a single Workarea with a single copy of any given folder-by-name. Consequently it becomes the default condition that individual developers will have a particular directory on their separate systems (e.g.) /home/userX/Workarea/Something but, for instance, user1 and user2 may have completely different views of what is in Something because user1 is using Something#42 while user2 is using Something#88.
A natural side effect of this new-speak is that the documentation tends to circular references. (paraphrased) "The folder command creates or modifies folders" and so on. In general, if you already know the product-specific vocabulary well enough to understand most of the documentation, you wont need to consult it. If you don't know the vocabulary very well, the documentation tends to the incomprehensible. The cynical-minded may then assume this explains the complete lack of access to the online documentation at the product site until after the license purchase is executed.
[edit] One Thing at a Time
The single work area and the multiple folders laid over a particular names phenomenon is implemented via a client program that is all to willing to obliterate the files on the disk in favor of the files in the database. As a developer you can expect to repeatedly lose lots of work until you get gun-shy. Explaining this lost work paradigm is something of a digression:
[edit] Prescience or Disaster, there is no third option
The lauded "task based" nature of the system expresses itself by requiring the developer to name, number, and describe the intent of his actions at code check-out instead of code check-in. These labels and numbers can be easily modified at check-in, but in practice the social engineering isn't there to make sure this happens in any meaningful way. This is arguably a feature, but in practice it requires the developer express their intentions too soon in the development process. Since files must be checked out to edit them, but they are available read-only in place, the developer will invariably just overwrite the files when doing speculative development. That is, the system actively resists "I'd like to see if method-X is better" speculative actions, so the developer must subvert the system. Having done that the client will willfully destroy that un-tasked work during some actions like changing the active folder (q.v. swapping Something#42 for Something#88).
Expect an unending number of tasks titled "Project X, Ongoing Development, Again" to litter your task history.
[edit] One Thing at a Time Revisited
There is exactly one "Work Area" per login per computer. [There is allegedly a means to subvert this paradigm by regularly diddling config settings back-and-forth to switch between work areas, but this is an out-of-workflow/out-of-spec hack so it won't be evaluated in this text.] This single work area paradigm all-but prevents the developer working on more than one task at a time. Consider two tasks, one that is short term and one that is long term. If those two tasks needs must touch the same file (e.g. the Makefile) then that file must be checked out to exactly one of those tasks. Committing that task will pull in the changes for the other task if they are not expunged before check-in manually. A developer may work on two conflicting changes only by making separate "folders" (not directories) with the same name and initial contents (e.g. the same task list) and then swapping back and forth between active folders. This implies that all the speculative and partial changes must exist in the database as checkpoints and private elements (which is supported). The less obvious implication is that the two tasks may only be analyzed (diff etc) using internal Synergy features because the developer only has one of the two versions available on their file system at a time. Further if the checkpoint versions are not manually removed by the developer before task check in, the database will be littered with potentially meaningless or harmful (confusing during code maintenance etc) non-working versions.
The above means that where, in CVS, a developer would simply check out the module twice in different directories, the Synergy user must develop a deep understanding of the database, client, and the implications of their actions; and then act repeatedly on the repository in order to switch mental gears.
[edit] All Roads Lead to Rome, expect to walk them all
Since version numbers are assigned to individual files at check-out, the default file management paradigm is to branch the file at each check-out. This means that if five developers check out Makefile, when they check in the Makefile version tree will be five branches wide. It is then incumbent on someone to eventually merge these five branches into one. This is orthogonal to the CVS (etc) methodology where branching a file is rare, and developers must resolve conflicts before check-in. Individual file history graphs naturally want to grow to impenetrable complexity.
For a busy project expect the "nightly build" to be very hit-or-miss unless your build manager is a Zen Grand-Master of merging the work of multiple developers.
[edit] Illusory Tasks (why tasks are not change-sets)
While everything is supposed to be task-based, it is possible to check in individual files via obvious menu options and such. This is required in order to make the checkpoint and folder swapping possible. Consequently a "Task" often, or even usually, spans many things that would or should be discreet in the change-set sense. This per-file check-in can lead to eternal tasks. Since code is accepted or rejected by task, having even one developer fail to understand the importance treating tasks as change sets "by consent" (meaning that each and every developer takes the one-meaningful-change, one task, one full-task check-in mantra to heart) can lead tasks that dare not be rejected etc.
These eternal tasks are almost encouraged by the product because of the way the command line and GUI tend to make single-file commits "feel safer". There is a big "commit current default task" button on the GUI, and you can commit a task by number using the command line, but then you tend to miss the chance to re-edit the per-file version and comment (rationale), which throws you back into prescience trap.
The all these file versions are associated with the task for the purpose of defining folders, but that's about it in practice.
[edit] Greedy Acquisition
The find unmanaged files type functionality lacks any kind of .cvsignore paradigm (or the feature is exceedingly well hidden) and will assign all the files it finds to the current default task.
[edit] No Warrant for You
The eternal task functionality effectively invalidates any warrant of historical access theoretically offered by this system. Some projects are required (in some cases by law) to be able to show complete traceability and rational (revisitable) version history. It only takes one Eternal Task that has one file with a complex (merged with changes from other tasks) version history to render a particular "historical version of the software" inaccessible, and two such tasks really messes things up.
Consider "Task#1" is eternal, with foo.c version 1 (and eventually versions 3, and 7) foo.c-version1 is checked in. Task#2 makes version 2 and the task is properly checked in. Task#1 makes version 3 and checks that version in. Task#3 makes version 4 and then makes version 5 as the merge of versions 4 and 3. Task#4 is eternal and makes version 6 and checks it in. Task#1 checks out version 6 and makes a huge-bu-unnoticed mistake while making version 7 and checks that in. Task#4 comes back and makes version 8 from version 7. The error is then noticed and the build manager also notices the eternal tasks (or just calls for a general freeze) and Task#1 and Task#4 are finally checked in as tasks.
Neither Task#1 nor Task#4 can be rejected outright, and in the normal turn of events there will be a version 8 via some Task#X, so "the VCS system worked"...
There is, however, no way to meet the full history and disclosure requirements because you cannot make a "folder" that contains a set of tasks that will net you foo.c-version-6. You can get close by synthesizing events with new tasks, but that isn't "what really happened" and so doesn't meet the managerial or legal requirement. You can also get there by doing piecemeal extraction and culling to a non-controlled directory, but that isn't a "Real Version" in the VCS sense.
[edit] The Good Parts
The proceeding list of issues is unremittingly negative, and that's bad form. There are good points to the system. Just as the issue list above is not exhaustive, the feature list below is not all encompassing.
[edit] A Real Database
There is a real, live database in this system. Not a patched together file system and a bunch of text analysis code. Anybody who has ever had a VCS die on them, or worse, start producing inaccurate version, because of a file system corrupted by an errant script (q.v. temp file cleaner) or that one developer who fancies themselves a RCCS file tweaker par excellence. Databases can, of course become corrupted too, but with a central database you have the option to instance a decent backup scheme and "know" that a restore will be a semantic all-or-nothing. It is hard to be too positive about the benefits of guaranteed cross-module data integrity when maintaining a VCS.
NOTE: The documentation often uses the word Database to refer to a staging store that is maintained separately on each workstation. This is the third-leg in the data integrity triangle and makes the network lean enough to fit across a pretty saturated channel. That database is silent magic so you should just take it as read and ignore its existence.
[edit] Restrictive Permissions
In the theoretically perfect world, everybody is honest and nobody minds admitting a mistake. Unfortunately your developers are not living in that world. Synergy provides (configurable) access controls that actually make sense. Oh, your developers may chafe over the controls a little, but that is just because they aren't the direct beneficiary of the restriction.
For example. If you accidentally add file to a folder/task and then check it in, it is in the database forever unless the build manager (etc) goes in and kills it administratively. That sounds like a bad thing, but it isn't really. The developer can make the file apparently disappear by normal means, that being create a task, check out the directory then remove (not delete) the file from the directory, and then check in the task. The file is gone, but it isn't gone.
The corollary to this is, of course, that barring a lot of mendacious administrative action, or an information apocalypse, absolutely nothing will ever be lost. Even mistakes are worth sometimes worth remembering.
[edit] No Take-Backs
Many VCS schemes allow for that subtle evil known as "relabeling". For instance, in CVS you can move tags between different versions and branches of individual files, which is evil incarnate, and just about anybody do the move. The only real reason to move a tag, barring some that live to move (q.v. "current_stable" etc) is so that someone somewhere can save face. We have all had the (generally harmless) experience of checking in and tagging what was supposed to be "version 3 final" only to discover something was missing from the check-in. The "traditional approach" is to quietly slip in missing stuff and move the tags. Well that's all fine and good, except for when the production build is already checked out, built, and burnt to 10,000 custom labeled CDROMs. When that happens there is just a bunch of finger pointing and proclamations of innocence.
Synergy deals with most of this by not even using tags in this way. I cannot even think of having seen a tag command in the classic sense.
When used correctly folders and versions make the exercise of tagging, and tag management, no-starters.
That means the attendant chicanery will disappear. And this is a classic case of Authoritarian and Patrician VCS is your friend.
[edit] A Decent GUI
This isn't the worlds best GUI, but for version control systems, and once you "get it", there are a few things that they just do right in the GUI. In particular once you have that complex file history, the clearly named "show history" context menu item brings up a very nice (if spartan) history graph that lets you easily do things like identify where you checked some file out and back in several times without changing it, or where you can comfortably prune the vaguely before-mentioned checkpoints versions.
We have an ugly but effective custom default color scheme; it's all green and purple and stuff, but the GUI was written by people who understand information display, so you can tell what is going on from ten feet away. The GUI actually helps when there are three of you in the room trying to figure out one stupid but trying issue.
[edit] Command Line Interface
Find it; when using Windows, put it on your path and use a good scriptable shell (like bash over Cygwin); and learn it. All GUI's have their flaws and the biggest is that sometimes you can do in a hundred clicks what would have burdened you with one command. Synergy is no exception in that case. With the command line utility you can do a lot of those per-file operations to a set of files instead. That alone is worth the cost of the chdir.
[edit] CLI and GUI are not Enemies
In lots of systems, the Command Line interface and the Graphic interface live in a world of Apartheid. In those fabricated implementations you can easily go astray.
Synergy, on the other hand (and possibly by reason of that local database you were told to ignore), is a near seamless union of the two otherwise independent interfaces. This is as it should be. Oh yea, every now and again you will start the CLI and eventually type exit, only to see the GUI go away in response. This is a minuscule price to pay.
For example (on windows at least), if you have logged in to the GUI the psudo-persistent options (like the very fact of your authenticated login and the "current default task") are automagically in force for the CLI. So you don't have to repeatedly specify a lot of the things that would otherwise make the CLI a chore.
[edit] There is no HEAD (there is only Zul)
NOTE: In the bad-things part I derided folders, a lot, and I still hate them with the passion of a thousand burning suns. But that is only because they are sufficiently hard for enough people to use correctly that when others miss-apprehend them in concert with Eternal Tasks they are a disaster waiting to happen. So why the re-enforcing rant against folders in the good parts section? It's the task's fault, really, But wait...
If you, or at least your Chief Architect and your Build Manager really come to understand folders they completely blow away the concept of tags and branch tags.
Since "folders" are really sets of tasks and sets of other folders, they can be a sublime tool. Consider a set of folders:
Project#1 => the common core of the project. Project#2 => Windows specific code. Project#3 => Linux specific code. Project#4 => Windows Compile-Ready image, contains folders Project#1 and Project#2. Project#5 => Linux Compile-Ready image, contains Project#1 and Project#3.
Depending on what you "Reconfigure" the Project node to be, the single directory (e.g.) /whatever/WorkArea/Project/ could have any one of 5 different sets of files in it. If you CODE to these assumptions you can even get rid of all the conditional code. Part of this magic is that the folders of the same name and relative position in the tree are "merged flat" at the root. So when you Reconfigure to Project#5 you get the tree /whatever/WorkArea/Project/(whatever) and NOT /whatever/WorkArea/Project#5/Project#1/(whatever) and /whatever/WorkArea/Project#5/Project#3/(whatever).
If the build manager does final task acceptance by bringing the tasks (and therefore their specific file versions) into the relevant constituent folder (e.g. 1, 2 or 3 in this example) (which can happen by automated magic the author has never seen since he is _not_ the build manager) you end up having this system where things flow into the center instead of scattering out towards "branches".
NOTE: see how use of "folder" instead of something that would say something like "task collection rooted in this location" just isn't a happy reuse of the word "folder".
[edit] Anonymous Non-Numbered Not-A-Checkpoint Storage
If, and only if, you manage to Zen into the way Reconfigure, and Reconcile, and Resync work you can do some amazing things. But until you do these are the commands that are going to make your hard work disappear. It's like the old saw, "Good, Fast, Cheap; pick any two". At any given time in the development VCS process you are going to want to use two of these commands, but if you use the third it will bite you. So once you get the hang of it all...
Any file that is checked out to (and therefore writeable by) you can be pushed from your workstation into the database WITHOUT actually doing a checkpoint or a check-in. This is how all that switching "folders" can be done. While you can not walk back through previous version (as you could with checkpoint versions or full check-ins), you can update the database from the work area or the work area from the database.
In lay terms, with one or two careful clicks you can do off-worstation (and potentially off-site) backups of your work in progress.
Implicit in this is the fact that if you add a file to version control, do this back-and-forth, and then delete the file from version control before it is ever checked in, the file DOES NOT persist in the Synergy database. This is a (deliberate?) feature that lets a developer or a company manage "hot" development work data backups without having to go to foreign solutions. (It does NOT violate the No-Take-Backs perk because this is a purely non-commit strategy and that is in keeping with the notion of committed versus non-committed transactions.) (Temporary files may, of course, end up on nightly backup tapes etc.
[edit] Tasks (Under Advisement)
I wanted to say something good about the "task based" model, but I find I damn with faint praise. If they could just resolve some of their procedural nudges so that Eternal Tasks were impossible, then I would have something good to say about the feature per-se.
If, however, you can discipline staff to think of and treat tasks as "change sets" and you have a Build Manager (and review team etc) who can churn tasks through the review and approve process quickly and accurately, the system can work quite well.
Until Synergy can get sufficiently authoritarian about this, the "task based" model touted as the main feature is an icy slope.
[edit] How Does the Reviewer Cope
The obvious and trite answer is that what you cannot fix you learn to live with. At the simplest level, when I am dealing with conflicting development requirements I get subversive. I started with just plain copy to move fragments in and out of the workspace. This was unworkable over time as it was too error prone. So I instituted my own parallel VCS. In particular I use the Monotone VCS.
I don't use Monotone to ape or parallel the whole of the VCS process by any means. Monotone has a suite of traits and properties that make it ideal as a workspace manager and analysis tool. It too has a "real database" and it out performs most VCS systems in the merge/diff/analyze arena. So I use Monotone the way a Draftsman uses isometric projections. I create an empty Monotone database instance. Load the offending sub-tree from the Subversion single work area, and then "check out" from monotone into the necessary number of parallel directories. I do the conflicting work in those parallel directories and use Monotone to project/condense them back into the Synergy work area. This can go on for several days or weeks. As I build and identify each suitable change set I project it from monotone back into the Synergy work area and commit the change set (task). When all the conflicting stuff is done with I DELETE the monotone database so that I won't be tempted to go back and consult it as if it were gospel.
In short I still use non-workspace copies, I just found the right ancillary tool to do the copying.
Others still use plain copy or network shares to side-publish things to other developers, which I suppose seems most telling about where Synergy does and doesn't come through. Take that with a grain of salt though, I have yet to use a VCS that didn't need to be subverted at least a little.
[edit] Executive Summary
This product has some excellent tactical elements, and some atrocious tactical elements, but strategically it is "problematic". In some places it is Authoritarian and Pedantic, while in others it is unforgivably Permissive in a way that screams "necessary hack." Many free (as in beer) and free (as in liberty) VCS systems are just as good when you tally comprehensively and unforgivingly. Some companies will be drawn to it despite its steep price because they can claim it meets their legal requirements for due diligence (because the brochures say it does, not necessarily because it inherently, actually does).
