The simplest approach to supporting multiuser access to a versioned geodatabase is for many editors to directly edit the DEFAULT version.

As each editor opens the DEFAULT version for editing, a new, unnamed, temporary version is automatically created; editors do not have to explicitly create a new version.

This temporary version is accessible only to the current editor, and it automatically evolves through the succession of states created by each new edit operation. When the editor saves his work or ends the edit session, this temporary version is automatically reconciled with and posted to the DEFAULT version.

If another editor has edited DEFAULT since the current editor started editing, when the other editor saves his changes, he receives notification that the version has been altered since the edit session began. The second editor's changes must be saved again to accept the results of the automatic reconcile operation that has just taken place. This automatic reconcile notification may be bypassed if required.

The multiple, concurrent edit sessions on the DEFAULT version have the following effect on the state tree.

Pros

• Simplicity—This versioning workflow is probably most applicable to situations in which the units of work are fairly small or persistent design alternatives are not required.
   
• If no conflicts are detected, the edits are directly posted to the DEFAULT version without user intervention.

Cons

• The DEFAULT version is constantly changing and is vulnerable to inadvertent or malicious modification. Specific action is required on the part of the database administrator to preserve a historical record of the changes made to the DEFAULT version.
   
• This workflow does not support long transactions, which typically span many edit sessions, or the creation of alternative design versions.
   
• There are some performance and workflow issues associated with this approach: if a number of editors save and reconcile their changes to the DEFAULT version at the same time, other editors may notice a degradation in response times for their own save requests. The ArcGIS application software automatically detects changes to the current edit version and will automatically reconcile and post if the version has been modified by another edit session. This is required for data and version consistency.
  
  Because version reconcile is a serial process—that is, only one reconcile operation per geodatabase can be active at any given time—these frequent reconcile and posts in every edit session can have a negative impact on performance and response times. Editors may also receive a warning that the target version has changed since they started their edit sessions; they must save again to accept the changes made by other editors and may have to wait for any active reconcile and post operations to complete before they will be able to complete their own.
  
  In a large, multieditor enterprise geodatabase, it is better to avoid situations where many users reconcile and post to a common parent. Reconcile and post exclusively locks the parent version. While this lock is in place, other users will be prevented from completing their tasks.
   
• As all reconcile operations are undertaken automatically, this approach does not support batch reconcile/post processes.