End-user collaboration library via 3-way xml merging and hg dvcs under the hood
C# XSLT Python Shell HTML Batchfile
Switch branches/tags
wesay1.5 wesay1.2 v2.5 closed/stable closed/proxySavvy closed/optimize closed/naylor closed/mono closed/lastufka closed/kstribley closed/header-etc closed/geckofx29 closed/geckofx22 closed/conflictWork closed/conflictMessages closed/chorusml closed/bugfix closed/beta closed/backgroundCheckin closed/autofac2ForDefault closed/XmlDiffTroubles closed/WinFormsDependency closed/WholeFileProcessing closed/UserNameWithSpace closed/UseChorusHubInGetSharedProjectCode closed/UseActualCloneLocation closed/UpdateLiftMergeStrategies closed/UpdateAutofacToDotNet4 closed/UnrelatedRepo closed/UnescapedAuth closed/TwoMinorMods closed/TestUtilitiesSpinOff closed/TestListenerSetsContext closed/SplitUpFieldWorksFileHandlerSystem closed/SimpleUpdateOverCalled closed/ShouldCreateConflictReport closed/Server_below_Internet_Button_2 closed/Server_below_Internet_Button closed/SelectNextNote closed/SegregateChorusNotes closed/SearchForHandlers closed/SaveMessageOnResolve closed/RootElementMissing closed/ResumableAsDefault closed/ReportChangesOnOtherBranches closed/ReplaceBogusElementInLiftData closed/ReorderLiftAndLiftRangesFiles closed/RemoveOseAndAiHandlers closed/RemoveNetworkFolderSharing closed/RemoveAmbiguousChildrenFixes closed/Regnier closed/RefineMergeTimeout closed/RefactorNWFSettings closed/RedoVersionBranching closed/RecoverIncompleteMerge closed/ReallyBlockV3Api closed/ReadMeInBareRepository closed/ReEnableBranchWarning closed/ParentOrderPolicy closed/OutputStatusOnFileError closed/OurWord closed/OptimizeXmlEqualityChecking closed/OptimizeLargeFileFilter closed/OnlyOneHubAllowed closed/OnlyMergeAttributesOnce closed/OneStory closed/OneMoreV3Rollback closed/NullRefOnKeyLookup closed/NotesBarWithoutHg closed/NotesBarExtensions closed/NestedFWFiles closed/NWFolderIOExceptionFix closed/MultipleConflictsDetails closed/MoreLargeFileFilteringFixes closed/MoreLargeFileFilterWork closed/MoreLDMLFixes closed/MoreAutfac2Migration closed/MonoGeckoFx13 closed/ModifyGetSharedProjectModelAPI closed/MergeMagnet closed/MergeLimitedChildrenService closed/MergeImprovements closed/LockingSRSetup closed/LiftBridge1.4Stabilization closed/LdmlGenDateConflict closed/LargeFilesInRepoFixes closed/LT-13794 closed/LT-13518_sort_messages closed/LT-12887 closed/LT-12871 closed/LIFTAdjunctDefaultFor013 closed/LDMLFixes closed/KeyboardingV2 closed/InvalidPathCharCrashFix closed/InternationalizationTry2 closed/Internationalization closed/ImproveTopLevelContext closed/ImproveReportTesting closed/ImproveNWFSettings closed/ImproveEditRemoveReporting
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
papers and presentations



Chorus is a version control system designed to enable workflows appropriate for typical language development teams who are geographically distributed. These teams need to edit a set of common files, working towards a publication. They want to share their work while, crucially, being able to defer dealing with conflicting edits for periods of time or until a qualified team member can make decisions about the conflicts. The system is implemented on top of a commonly-used Open Source Distributed Version Control System. It works in scenarios in which users are connected by Local Area Network, Internet, or hand-carried storage devices. Chorus supports several workflow models, including those that maintain a “master” database separate from the incoming submissions of team members. Quite unlike the version control systems commonly in use, Chorus works invisibly for the common cases and is kept simple for even beginner computer users.

Distinctive Features

These features come for free with any Distribute Version Control System:

  • Share files between users, even if they are never connected to the internet.

  • Every member of the team has access to a full history of all work done by the rest of the team.

  • In a crisis, work can be "rolled back" to a previous version.

However, "raw" Distributed Version Controls Systems are relatively difficult to understand, configure, and use, even for computer-savvy workers.

The following list of features should help you understand why we built this layer over a raw version control system:

  • silently synchronize; will never tell the user to manually merge conflicts first

  • automatically check for team members & devices with which to synchronize

  • Support a Master branch which does not automatically accept changes from anyone

  • Files can be marked as shared by the team or user-specific. This allows things like preferences/configurations to be part of the repository, but kept separate for each individual. This will also allow one team member to make configuration changes for another, remote member, and push those changes through the system to that user, without physically accessing their computer.

  • 3-Way, schema-savvy XML merging. Various policies can be implemented for choosing a winner in the case of conflicts. Regardless of the policy, details of the conflict are logged in an xml file which also under version control. At a time and place of the team's choosing, these automatic choices can be reviewed and reversed.

  • Configuration help from applications. Applications generally know where their important files are, which files are individual-specific, and which should not be backed-up/shared at all. Applications that know about Chorus pass this information to it, so that users don't need to become experts in how all the files work.

  • Synchronization help from application. Applications often know what points are good ones for checking data in. For example, when exiting, or before doing a large and possibly undesirable operation, like deleting a large number of items or importing a new data set.

  • In-Application conflict and change history. Rather than ask users to learn version-control-specific tools, the Chorus model is that Chorus provides the raw information applications need to provide a smooth, integrated workflow in the same environment as the user has for editing. For example, a dictionary-editing program using Chorus will allow the user to see a full history of the current record, including who made what changes, and what conflicts (if any) were encountered during synchronization.

  • A built-in "notes" system which makes it very cheap to give users the ability to add notes to any piece of data, and to carry on conversations about about the data until they mark the note as "resolved".


Chorus is functional and being used in several applications with different development teams. However, we are not really interested in supporting any further uses until things mature and someone writes good develop documentation. Documentation (what little exists) drips out in the form of occasional blogs here.


Please see Tips for Testing Palaso Software


Mailing List

Sign up here: https://groups.google.com/forum/#!forum/chorusdev

Road Map & Workflow


Coding Standards

Palaso Coding Standards

Source Code

Chorus is written in C#. The UI widgets use Windows Forms, but you could make your own using a different platform and just use the engine.

After cloning the project you should now have a solution which you can build using any edition of Visual Studio 2010, including the free Express version. We could help you do it in VS 2008, if necessary.

On Linux you can open and build the solution in MonoDevelop, or run the build/TestBuild.sh script.

Getting up-to-date libraries

The source tree contains a script that downloads all necessary dependencies.


Open a "git bash" window, then change into the build directory and run the buildupdate.win.sh script:

cd /c/dev/chorus/build

Alternately, if you are working on libpalaso or another dependency, you can update to your local build using UpdateDependencies.bat, which is run automatically when you run GetAndBuildThis.bat:

cd c:\dev\chorus

If developing on windows, unzip the file lib/common/mercurial.zip into output/Debug (or output/Release), so that you'll end up with a subdirectory output/Debug/Mercurial. That way, you know the tests are running against the approved version of Mercurial, not whatever you happen to have on your machine.


In order to build and run all the tests on Linux the SIL mono package will need to be installed. It can be found at http://packages.sil.org/ That version of mono will be used when you run build/TestBuild.sh

Open a terminal window, change into the build directory and run the buildupdate.mono.sh script:

cd chorus/build

Alternately, if you are working on libpalaso or another dependency, you can update to your local build using UpdateDependencies.sh:

cd chorus