4.4. Committing Your Changes To The Repository
Sending the changes you made to your working copy is known as
committing the changes. But before you
commit you have to make sure that your working copy is up to
date. You can either use
→
directly. Or you can use
→
first, to see which files have changed locally or on the server.
If your working copy is up to date and there are no conflicts,
you are ready to commit your changes. Select any file
and/or folders you want to commit, then
→ .
The commit dialog will show you every changed file,
including added, deleted and unversioned files. If you don't
want a changed file to be committed, just uncheck that
file. If you want to include an unversioned file,
just check that file to add it to the commit.
Items which have been switched to a different repository path are
also indicated using an (s)
marker. You may have
switched something while working on a branch and forgotten to switch
back to trunk. This is your warning sign!
| Commit files or folders? |
---|
When you commit files, the commit dialog shows only
the files you have selected. When you commit a folder
the commit dialog will select the changed files automatically.
If you forget about a new file you created, committing the
folder will find it anyway. Committing a folder does not
mean that every file gets marked as changed; It just makes
your life easier by doing more work for you.
|
| Many unversioned files in the commit dialog |
---|
If you think that the commit dialog shows you too
many unversioned (e.g. compiler generated or editor backup)
files, there are several ways to handle this. You can:
add the file (or a wildcard extension)
to the list of files to exclude on the settings page.
This will affect every working copy you have.
add the file to the svn:ignore list
using
→
This will only affect the directory on
which you set the svn:ignore property.
Using the SVN Property Dialog, you can alter the
svn:ignore property for a directory.
Read Section 4.13, “Ignoring Files And Directories” for more information.
|
Double clicking on any modified file in the commit
dialog will launch the external diff tool to show your changes.
The context menu will give you more options, as shown in the screenshot.
You can also drag files from here into another application such as a
text editor or an IDE.
You can select or deselect items by clicking on the checkbox to the
left of the item. For directories you can use Shift-select
to make the action recursive.
The columns displayed in the bottom pane are customizable. If you
right click on any column header you will see a
context menu allowing you to select which columns are displayed.
You can also change column width by using the drag handle which
appears when you move the mouse over a column boundary. These
customizations are preserved, so you will see the same headings
next time.
By default when you commit changes, any locks that you hold on files
are released automatically after the commit succeeds. If you want
to keep those locks, make sure the Keep locks
checkbox is checked. The default state of this checkbox is taken
from the no_unlock
option in the Subversion
configuration file. Read Section 4.30.1, “General Settings”
for information on how to edit the Subversion configuration file.
| Drag and Drop |
---|
You can drag files into the commit dialog from elsewhere, so
long as the working copies are checked out from the same repository.
For example, you may have a huge working copy with several
explorer windows open to look at distant folders of the
hierarchy. If you want to avoid committing from the top
level folder (with a lengthy folder crawl to check for changes)
you can open the commit dialog for one folder and drag in items
from the other windows to include within the same atomic commit.
You can drag unversioned files which reside within a working copy
into the commit dialog, and they will be SVN added automatically.
Dragging files from the list at the bottom of the commit dialog
to the log message edit box will insert the paths as plain text
into that edit box. This is useful if you want to write commit log
messages that include the paths that are affected by the commit.
|
| Repairing External Renames |
---|
Sometimes files get renamed outside of Subversion, and they show up
in the file list as a missing file and an unversioned file. To avoid
losing the history you need to notify Subversion about the connection.
Simply select both the old name (missing) and the new name (unversioned)
and use
→
to pair the two files as a rename.
|
| Repairing External Copies |
---|
If you made a copy of a file but forgot to use the Subversion command
to do so, you can repair that copy so the new file doesn't lose
its history.
Simply select both the old name (normal or modified) and the new name (unversioned)
and use
→
to pair the two files as a copy.
|
The commit dialog supports Subversion's changelist feature to help
with grouping related files together. Find out about this feature
in Section 4.8, “Change Lists”.
4.4.3. Excluding Items from the Commit List
Sometimes you have versioned files that change frequently but that you
really don't want to commit. Sometimes this indicates a flaw in your
build process - why are those files versioned? should you be using
template files? But occasionally it is inevitable. A classic reason
is that your IDE changes a timestamp in the project file every time
you build. The project file has to be versioned as it includes all the
build settings, but it doesn't need to be committed just because the
timestamp changed.
To help out in awkward cases like this, we have reserved a changelist
called ignore-on-commit
. Any file added to this
changelist will automatically be unchecked in the commit dialog.
You can still commit changes, but you have to select it manually
in the commit dialog.
4.4.4. Commit Log Messages
Be sure to enter a log message which describes the changes you are
committing. This will help you to see what happened and when, as you
browse through the project log messages at a later date. The message
can be as long or as brief as you like; many projects have guidelines
for what should be included, the language to use, and sometimes even
a strict format.
You can apply simple formatting to your log messages using a convention
similar to that used within emails.
To apply styling to text
, use
*text*
for bold,
_text_
for underlining, and
^text^
for italics.
TortoiseSVN includes a spellchecker to help you get your log messages
right. This will highlight any mis-spelled words. Use the context menu
to access the suggested corrections. Of course, it doesn't know
every technical term that you do, so correctly
spelt words will sometimes show up as errors. But don't worry. You can
just add them to your personal dictionary using the context menu.
The log message window also includes a filename and function auto-completion
facility. This uses regular expressions to extract class and function names
from the (text) files you are committing, as well as the filenames themselves.
If a word you are typing matches anything in the list (after you have typed at
least 3 characters, or pressed Ctrl+Space),
a drop-down appears allowing you to select the full name.
The regular expressions supplied with TortoiseSVN are held in the TortoiseSVN
installation bin
folder. You can also define your own
regexes and store them in %APPDATA%\TortoiseSVN\autolist.txt
.
Of course your private autolist will not be overwritten when you update your
installation of TortoiseSVN. If you are unfamiliar with regular expressions,
take a look at the introduction at
http://en.wikipedia.org/wiki/Regular_expression
,
and the online documentation and tutorial at
http://www.regular-expressions.info/
.
Getting the regex just right can be tricky, so to help you sort out a
suitable expression there is a test dialog which allows you to enter
an expression and then type in filenames to test it against.
Start it from the command prompt using the command
TortoiseProc.exe /command:autotexttest
.
You can re-use previously entered log messages. Just click on
Recent messages to view a list of the last few
messages you entered for this working copy. The number of stored messages
can be customized in the TortoiseSVN settings dialog.
You can clear all stored commit messages from the Saved data
page of TortoiseSVN's settings, or you can clear individual messages from
within the Recent messages dialog using the
Delete key.
If you want to include the checked paths in your log message, you can use
the command
→
in the edit control.
Another way to insert the paths into the log message is to simply
drag the files from the file list onto the edit control.
| Special Folder Properties |
---|
There are several special folder properties which can be used to
help give more control over the formatting of commit log messages and
the language used by the spellchecker module.
Read Section 4.17, “Project Settings” for further information.
|
| Integration with Bug Tracking Tools |
---|
If you have activated the bug tracking system, you can set one or more
Issues in the Bug-ID / Issue-Nr: text box. Multiple
issues should be comma separated. Alternatively, if you are using
regex-based bug tracking support, just add your issue references
as part of the log message.
Learn more in Section 4.28, “Integration with Bug Tracking Systems / Issue Trackers”.
|
After pressing OK, a dialog appears displaying
the progress of the commit.
The progress dialog uses colour coding to highlight different
commit actions
- Blue
Committing a modification.
- Purple
Committing a new addition.
- Dark red
Committing a deletion or a replacement.
- Black
All other items.
This is the default colour scheme, but you can customise those colours
using the settings dialog.
Read Section 4.30.1.4, “TortoiseSVN Colour Settings” for more information.