Sean's answer is a good general overview of the differences between Unicorn and TDS Classic. This answer is here mostly to expand on a few of the serialization-based items not entirely covered.
The real best way to decide what you want to use is to actually try using both. Each has its own distinct advantages for different types of projects and different dev team cultures. Hedgehog will give you a trial version of TDS Classic, and I'll give you a free version of Unicorn forever. Go play!
Your Preferred Environment
TDS Classic is highly geared towards developers who spend their day in Visual Studio, as that's where all of its UI lives. With TDS, you'll manage your items, configuration, item syncing, and all that from within Visual Studio. If that's your thing, TDS is your product.
Unicorn is designed to have, and require, as little UI as possible. It does not require the use of any specific IDE tool, and though it has a sync UI it's mostly designed to be run from a script as part of some automated process (e.g. a build/deploy script). It gets away with this because of how it syncs.
What 'Sync' Means in Each
[Updated]
In TDS Classic, 'Sync' means the process which starts with a comparison window, displaying the differences of items on disk and in Sitecore. That window is then be used to push or pull each item's content to/from Sitecore. TDS offers this 'Sync Window' comparison in various granularity levels with the following features:-
- Sync this item - comparing just the chosen item only
- Sync with Sitecore - to compare all of the items in a TDS project, or sub-project hierarchy.
- Sitecore using History - comparing the items within a TDS project by displaying the most recently modified/added/deleted items only
- Sitecore all TDS Projects using History - as above, but for all TDS Projects in the solution.
- Sync all projects in Sitecore - a full comparison of every item in every TDS project across the entire solution.
In Unicorn a 'Sync' is the process by which Sitecore is updated to match what is on disk. Unicorn treats the disk as the master copy, so a 'sync' will make Sitecore match everything on disk.
Unicorn offers granular syncs with:-
- configuration-level sync (which might typically be a per-project configuration)
- all-configurations sync (to do a solution-wide sync with one operation)
A 'sync' in Unicorn is a pure push mechanism, where Sitecore items will update, but the process won't update any serialized items on disk. Whereas for TDS, a 'sync' may result in both Sitecore items, and serialized files being updated.
The end result for both will be that the disk items and the Sitecore items will match (i.e they'll be in sync).
How Items and Pushed/Pulled between Sitecore and Disk
[Updated from the comments]
TDS Classic
With TDS Classic the serialized items and Sitecore items can both be updated with features from within the IDE through the TDS Classic Visual Studio Extension.
Then the 'Sync' features mentioned above will allow you to do both pushing and pulling of items. There are also other features in TDS that allow you to perform these operations.
Pushing Items - The 'Deploy' and 'Quick Push' features will push the items from disk to Sitecore.
Pulling Items - The 'GetSitecoreItems' features will pull items from Sitecore to disk, while the AutoSync feature will pull the updates automatically when turned on.
Unicorn
Pushing Items - a 'Sync' operation in Unicorn, as mentioned above, will update Sitecore to match what is on disk. Transparent Sync, when turned on, also updates Sitecore items to match the serialized items, but does so automatically, instead of requiring syncing to be triggered from the control panel.
Pulling Items - As Unicorn utilizes the Data Provider, updates made within Sitecore are also updated on disk, so the 'pull' aspect is done automatically.
Unicorn also features a 'Re-Serialize' operation, where items are also pulled from Sitecore onto disk. This operation is typically only used for initial project setup, and for configuration changes where different sets of items are being pulled into the project.
Unlike TDS, there is no comparison UI because the serialized file is always treated as the master. The disk is kept up to date as items are changed in Sitecore, and a 'sync' operation always pushes the item wholesale into the Sitecore database.
Conflict Resolution
Inevitably when working with a team, two developers will change the same item which might then cause a conflict in a serialized item file.
TDS Classic uses Sitecore's built in serialization format, which itself is a custom, inflexible, line-oriented format that is quite picky (requiring specific line endings, as well as calculated content-lengths for field values). When a conflict occurs on disk, dealing with this format can be painful when using regular file merge tools (like WinMerge, KDiff, TortoiseMerge etc.) because it doesn't know how to deal with them.
To combat this, Hedgehog developed a custom Sitecore Item Merge tool to handle this format for you, taking away that pain. It is automatically configured for TFS when TDS is installed, but can easily be configured for any source control provider like Git or SVN.
Unicorn uses its own custom developed format (based on YAML) that was designed from the ground up to be extremely mergeable. Entire classes of conflict can be auto-resolved by source control without it even becoming a conflict in the first place. However when there is still a conflict requiring human intervention, the line-by-line format allows for a very easy side-by-side comparison and resolution.
Deployment Methodology
[Updated from the comments]
With TDS Classic, deployments can be done in a number of ways.
- Sitecore Connector Deployments - a web service is installed into your site, and MSBuild can connect directly to it to deploy your items. This might be typical for a DEV and QA environment deployment, and closely mimics how TDS deploys to your local as well.
- Update Package Deployments - TDS allows you to generate an update package (Sitecore standard) during the build, which can act as a deployment artifact that you manage.
You can then deploy that package in whichever way you want (through Sitecore.Ship, SitecorePackageDeployer, Sitecore PowerShell Extensions, UpdateInstallationWizard etc.).
The package contents can be configured for however flexible you want your deployments to be. You can have items and code together, items only (if you deploy your code some other way), or delta packages with only recently modified items (if you're looking to reduce deployment times).
For production deployments typically an Update Package is what most teams use, customizing their own deployment strategy to suit their needs.
Unicorn also doesn't really dictate how you choose to deploy your items either. Personally I tend to deploy all the serialized items and use the remote PowerShell API to script a sync operation immediately after the code is deployed. But others are using any number of techniques, including deploying the serialized items and manually triggering the Sync from the control panel, or using Sitecore Courier to generate update packages like TDS.
