Restore Scenarios

In typical usage, GitCentric displays a message like the following for each Git branch that is successfully restored:

Processing branch refs/heads/master in repository /sandbox/llowry/tmp/ws/git/Repo2.git/
==============================
Branch is in sync with the GitCentric database.

When the restore is successful, no action is required on the part of the GitCentric administrator. The remainder of this section describes other scenarios that require the attention of the GitCentric administrator.

Overflow

An overflow condition occurs when the GitCentric database is backed up before the Git repositories are copied. In this event, it is possible that the GitCentric database and the Git repository copies are out of synch, specifically, the GitCentric database probably does not have a complete set of AccuRev transaction-Git commit pairs reflecting the latest commits in the Git repositories.

When this happens, the GitCentric restore:

Identifies the latest mapped Git commit of which it is aware and resets the head there.
Creates a new branch that contains the commits that are not recorded in the GitCentric database. The new branch is named kando_backup_overflow_<name> where <name> is original branch name.

Writes a message to output like the following:

Processing branch refs/heads/maint in repository /sandbox/llowry/tmp/ws/git/Repo2.git/
==============================
Creating kando_backup_overflow_maint; review divergence with maint and merge as necessary.

In the case of an overflow condition, it is up to the GitCentric administrator to determine whether or not these changes need to be merged into the original branch and pushed to the Git repository. If the changes represented by the unrecorded commits are already in Git, GitCentric will automatically export them to the restored repository after you start the GitCentric server. If the missing changes are not in Git, the user can clone, then fast forward-only merge from the overflow branch to the named branch, and push.

Rollback

A rollback condition can occur when there is a large interval of time between when the copy of the Git repositories was created and the GitCentric database backup was performed. In this event, the GitCentric database will have recorded Git commits which are not in the restored repositories.

When the GitCentric restore encounters a rollback condition, it writes a message to output like the following:

Processing branch refs/heads/hotfix in repository /sandbox/llowry/tmp/ws/git/Repo1.git/
==============================
Rolling back mapped transactions that are higher than 61.

In this example, the GitCentric administrator needs to be aware that any Git transaction-Git commit pair greater than transaction number 61 is not known to the Git repositories. GitCentric has rolled back database transactions to 61, the last value known to the Git repositories. Users that have any missing changes in their clone should push them again.

Missing Branch in the Repository Copy

If GitCentric restore cannot locate a branch, it writes a message to output like the following:

 Processing branch refs/heads/spec in repository /sandbox/llowry/tmp/ws/git/Repo1.git/
==============================
Branch could not be found. Make sure the repository is at the expected location with the appropriate branch.

In this case, the GitCentric administrator needs to ensure that the copies of all Git repositories have been copied to their original location (that is, the location at the time the GitCentric database backup was created) and that all expected branches are present in those repositories. You may need to delete and recreate the branch mapping in GitCentric.