AnkhSVN

Commit and Pending Changes

The Pending Changes window is the main place to review local Subversion changes before sending them to the repository.

A commit publishes selected working-copy changes as one repository revision. Until the commit succeeds, edits, adds, deletes, moves, and property changes remain local.

Add is not Commit. Adding or scheduling a path only changes the working copy; nothing is published to repository history until commit succeeds.

Recommended commit workflow

Update or check status so you understand changes made by other people.
Review modified, added, deleted, moved, conflicted, and property-changed items.
Diff important files before committing.
Select only the files that belong to this logical change.
Resolve any conflicts.
Enter a useful log message that explains why the change was made.
Review issue references or changelists if your project uses them.
Commit.
Check Pending Changes afterward for anything you expected to include but did not.

Checking and unchecking changes

Use All Changes above the Pending Changes file list to clear every checked item, including items in other changelist groups. A mixed selection is also cleared in one click. Click again to check all eligible changes; items in the ignore-on-commit changelist remain unchecked.

The checkbox reflects individual file selections and is disabled when the list is empty. It is available across the supported Visual Studio versions (2022 and later, including 2026) independently of the list header’s theme.

What happens during commit

Subversion sends your selected working-copy changes to the repository as a transaction. A successful repository commit is atomic: the selected changes become one new repository revision together. A failed commit does not partially publish some of the selected changes as a normal successful revision.

Committing does not automatically update every untouched path in your working copy to HEAD. Your working copy can therefore contain mixed BASE revisions.

Out-of-date errors

Subversion protects repository history from blindly overwriting newer changes. If a path you are trying to commit is out of date, the commit may be rejected.

When that happens:

Preserve any important local work.
Update the affected working copy.
Resolve any conflicts created by the update.
Review and test the combined result.
Commit again.

An update is not a substitute for reviewing what changed.

Added and deleted files

Add schedules an unversioned item for addition. The file does not exist in repository history until commit.

Delete schedules a versioned item for deletion. The repository still contains its prior history; the deletion becomes part of history when committed.

Moves and renames are also working-copy changes until committed.

Property changes

Properties such as svn:ignore, svn:externals, svn:eol-style, and svn:mergeinfo are versioned changes too. Review them alongside file-content changes.

Changelists

Subversion changelists are local organizational labels for working-copy files. They are useful when your working copy contains changes for more than one task.

Changelists:

do not create repository branches,
do not become repository history,
are not shared with other developers,
do not allow two unrelated changes to the same file to be separated automatically.

Issue references

AnkhSVN can integrate issue IDs into the commit workflow.

With Local SVN Issues, the Pending Changes window shows an Issue field. Entering a local issue number adds Issue #<id> to the commit message.

With Generic Bugtraq, AnkhSVN uses the standard Subversion bugtraq:* properties. Depending on the configured properties, the commit UI can show an issue field, validate numeric IDs, remind you when no issue is entered, and build the configured issue reference into the log message.

Issue references become ordinary repository log-message text. They do not automatically change an issue’s status unless a connector explicitly implements that behavior.

See Issue Tracking Integration for setup, Local SVN Issues, Generic Bugtraq, changing/removing trackers, and external connectors.

Before committing a merge

A merge changes your working copy first. Before committing a merge:

review the diff,
verify any svn:mergeinfo changes,
resolve conflicts,
build/test the result,
avoid mixing unrelated local edits into the merge commit.

See Merge and merge tracking.

Before committing generated or unexpected files

If an item appeared unexpectedly, determine whether it should be versioned before selecting it. Build output, caches, local settings, secrets, and machine-specific files usually belong in ignore rules rather than repository history.