Tour: SmartGit As SVN Client

This page provides a quick overview of how SmartGit can be used as an SVN client. The first step is to check out from an SVN repository into a new working tree.

Checkout

With SmartGit, a Check Out is as simple as entering the repository URL ...

... and working tree location in a setup assistant, as shown below.

Main Window

When the checkout is completed, SmartGit's main window will look like the one below, with a directory tree on the left and a file table on the right. The latter is fully recursive, i.e. it shows all files in the directory that is currently selected in the directory view, and all files beneath that directory. In this case, this means the file table shows all files in and beneath the root directory my-working-copy.

As you can see, there is a file named GsDiffEntry.java that shows up as modified in the Working Tree State table column.

Commit

Next, let's commit our changes. One way to do this is to click on the Commit button in the toolbar. This opens a Commit dialog, as shown below. After entering a commit message and clicking Commit, our changes are committed. Note that the changes have not been sent to the repository yet, as will be explained shortly.

Log

Now, when we open the Log, we can see that our recent commit is shown at the top of the Commits table (on the top left).

Notice the colored trunk and svn/trunk markers in the Commits table? The trunk marker is always attached to our latest commit, while the svn/trunk marker is always attached to the latest commit in the SVN repository. Importantly, our latest commit and the latest commit in the SVN repository are not one and the same! This is due to the fact that SmartGit does not automatically send commits to the SVN repository — it does so only after you invoke an operation called push. Before a commit is pushed, it is simply stored in the local Git repository by SmartGit. The extra push step may seem inconvenient, but is in fact a major advantage:

• You can commit without being connected to the SVN repository.
• Commits that haven't been pushed yet can be modified, undone, reordered, joined, split, etc.

Now, some versioning 'purist' will of course reject the very idea of rewriting history. However, the ability to rewrite history can, if used judiciously, be a very nice thing to have in your toolbox: It allows you to freely group related changes and separate unrelated changes, resulting in a commit history that is overall cleaner and therefore much easier to analyze later. This could, for instance, be of much help when you later try to pin down the one commit in which some critical bug occurred for the first time.

Commit Modification

As an example of commit modification, we will now undo our last commit and split it into two commits. This makes sense in our case because the commit we created consists of two unrelated sets of changes that should have been committed separately.

After undoing the last commit, the file changes in the undone commit have automatically been moved to a special storage area called the Index. — The Index is basically a collection of file changes to be committed next. In order to create two separate commits from our file changes, all we have to do is move the first set of file changes to the Index, perform a commit, then move the second set of file changes to the Index and perform another commit.

Moving changes into and out of the Index is easy and intuitive, thanks to SmartGit's built-in Index Editor: As shown below, the Index Editor consists of three text editors, which represent the Git repository state, Index state and working tree state, respectively, of a particular file — in this case GsDiffEntry.java, the file we modified. All changes are highlighted in the Index editor, and moving them into and out of the Index is a simple matter of clicking on the buttons between the three text editors.

In the screenshot, you can see that our file contains four changes in total. Also, we have moved the first change to the Index while leaving the others in the working tree. Now, when we perform a commit, only the first change is committed (since it's the only one in the Index). For the second commit, there's no need to use the Index editor: We'll just commit everything that's left.

Now that we're done with editing commits and are sufficiently satisfied with our work, we'll perform a push, i.e. we'll send our commits to the SVN repository.

A quick glance at the Log window confirms that our initial commit has been split into two commits. You can also see that the trunk and svn/trunk markers are now attached to the same commit, meaning that our checkout and the SVN repository are at the same revision. — This is due to the push we performed.

Conclusion

We'll conclude our tour with creating a tag for our last commit. As you can see below, we added the tag 1.2.3 to the last commit.

Like commits, tags are stored in the local Git repository first, allowing you to freely manipulate them before you push them to the SVN repository:

For further information, please refer to the SmartGit manual.