Synchronising with Repositories

 

For many years now, working in groups, or simply wanting to protect valuable source code, programmers have used "Version Control Software" to make sure that changes to any part of the code-base is populated throughout the group. There are a number of systems available, and AmigaOS4 has direct support for both CVS and SubVersion.

The plugins that are currently available to CodeBench users are simply "frontends" for the client programs, so as a consequence, the clients will need to be downloaded and installed before attempting to use either the CVS or the SubVersion plugins. The relevant client programs can be downloaded at:

CVS Client from os4depot.net

SubVersion client from os4depot.net

Installation of both of these programs is explained in the documentation that is included in each archive respectively.

 

 

 

 


Using the cvs.syncplugin

This plugin is simply a set of requesters that prompts the user for an action, and depending on the response, performs that action by running the client program with the correct arguments.

The source code for this plugin is included in the SDK directory of each CodeBench version to allow an example of how third-party programmers could create plugins for other types of version control systems, or even improve on the basic plugins supplied.

 

back to the top

 

 

 

 


Using the svn.syncplugin

As in the example cvs plugin, this too uses a simple system of requesters to interact with the user, and performs tasks by running the installed svn client program. While the source-code for this plugin is not supplied, it is closely based on the cvs.syncplugin above.

 

back to the top

 

 

 


Using the svnbench.syncplugin

This plugin is a fully featured version of the svn.syncplugin. It allows the user to manipulate the files within the "working copy" (the local mirror of the files hosted on the remote server).

 

 

To illustrate the usage of this plugin, which can be used with any SubVersion server, we shall create a new project and "checkout" some source code which we can then manipulate with SVNBench.

First, lets run CodeBench, and create a new project. For this exercise, we need to select the "AmigaOS4SDK" type of project.

 

New SVN project The project name doesn't matter for this project, as we are only testing. As such, we have created a new directory in the RAM Disk: called "Test", and this is where we will download (checkout) the source code into.

In order for this project to use any of the Version Control plugins, simply select the appropriate option, and enter the name of the plugin we shall use in the gadget below. You may also use the GetFile gadget gadget to select the plugin from a file requester.

All other options in the other tabs can stay at their defaults.

Now select button to save the project file. You will probably be asked whether you wish to create the project directory, so just answer . After the dictionary has loaded (not applicable in the SE version), you will be left with an empty project list. Normally, when creating a new project, we would opt to add some files from the project directory, but we shall use SVNBench to add files from a SubVersion "repository" (A remote server which controls all files in a particular project).

Select the "Synchronise" menu, and the SVNBench window will open. SVNBench has recognised that the project directory does not currently contain the required SVN files, and is asking you if you want to create a new "working copy" (a mirror of the files in the repository), which of course we do. Click the button to open the settings window.

SVN url As an example, we are going to checkout the "http-handler" source code from openamiga.org.

The first thing we need to supply is the URL of where the source code is located, and this information is given on the project page of the OpenAmiga website. Like most SubVersion repositories, it requires a username and a password.

If you are using the standard SVN client (called "svn"), this will save your login credentials in a set of authorisation files. This saves having to enter the details each time you synchronise with the repository, and this plugin will use those files to locate and use any saved credentials. This is especially useful to save you having to remember and enter those details here. If you haven't used the svn client outside of this plugin, then these should be entered into their respective gadgets.

There are open repositories around which allow anyone to access, but we have chosen OpenAmiga for our example as their projects are relatively small, and are OS4 specific (yes, favouritism - ed!). It does require the user to open an account prior to using its SVN services though, so please see the website for more details.


The "SubVersion" tab is used to specify where on disk the client program lives. The default installation of the SVN client creates a "SubVersion:" assign and the "bin" directory is added to the system path. What this all adds up to is that the system can find the SVN client program without needing to be specifically told where it is. In this case, the default setting in this tab can be left alone. If you have the client program installed somewhere special that the system doesn't know about, enter the full path to the client. The SVN client can be downloaded from os4depot.


The "Directories" tab allows you to specify different directories for a "Commit" or "Update" operation.
It is possible that your project directory is not the "root" of the repository. For example, you might be using the "src" directory for your project, but the actual repository contains files or directories that are in the parent directory. When performing an "Update" operation from the project directory would miss any updated files from the root. For this reason, you can specify the parent directory in the relevant gadget so that all files will get updated.
The same theory applies to any "Commit" operations as well


Lastly, the "Display" tab allows you to set or edit the filter used to display files in the main list.
The same filter is displayed in the main window under the list of files, and is used to show files that match this pattern. For example, if you entered "#?.c" into the filter, then only files with a ".c" file extension would be displayed.
Thanks to the power of DOS pattern matching, you can develop some rather extensive patterns to filter out most of the files you are not interested in. Obviously, it is not wise to filter out any files that are part of the repository (working copy), as you will not be able to see the status of such files, but it is very handy to filter out files that may be inconsequential to the project, like meta data and settings files.

It is always possible that the filter may mask out a file that is part of the working copy, so you may encounter a status display that shows changed files but none are visible. In this case, you can use the "checkbox" gadget at the end of the filter in the main window to temporarily disable it to allow you to see all the files.

Selecting will store the details you entered so that they do not have to be entered again, and the process of checking out (downloading) the files will begin. Bear in mind that this is transferring files over the internet, so the speed of this operation will very much depend on your connection to the server. Once the checkout has finished, you should see something similar to this:

SVN Checkout complete This shows what files were downloaded. The last line tells you what version the working copy is, and will be the most recent on the server. You can checkout earlier versions of the repository, more on that later.

OK, now we have the source in our working copy, we can pretty much do what we like with it. Of course, the usual purpose of this procedure is to make some changes to the code and once those changes have been made, the modified files need to be uploaded (committed) back to the repository. This allows any other developers that come along, like us, to checkout the changes that have been made. This way, everybody is working with the latest versions of the files.

In case you are thinking that there might be two programmers working on changing the same file, yes, it's a valid point. Luckily, this is one of the main goals of version control software and its handling of such situations. The software will handle "merging" the changes in the two files to create one file with the changes from both. This is an extremely powerful feature, and it ensures that files stay current. Of course, there's only so much that can be automated, and if the software cannot merge the changes because they are too extensive, it will mark the files as requiring our attention (in conflict), and the changes will then have to be merged manually.

One of the rules that affect the ability to be able to automatically merge changes is: "Commit often". This means that the amount of changes that have to be handled at any one time is a lot less, so the chances of a successful merge is much higher.



You'll notice that there are a number of buttons at the top of the SVNBench window, and these control certain functions, like adding and removing files, viewing certain properties of files etc. We shall discuss the specific function of each button a bit later on in the detailed view, but for now the first button we will use is the green circular button which displays the "status" of the working copy (the local files).

The status output, on the freshly checked out files, will look like this: SVN Status

 

Here we see all the files that are in the project directory, and their state. Because we have not yet changed any files, they are all as they were when we checked them out, so they are unchanged (displayed in green).

Any subdirectories are displayed in the list as well as the files. You may also notice a ghosted file in the list, which is the SVNBench settings file for this project, and because it is not part of the working copy, it is labeled as such. You may mask out files that are not part of the working copy by using the filter system.

Now we shall make the changes we require to the files in this project, and we can see what effect this has on the display from SVNBench. Click the button, and then add the newly checked-out files to the project. For our purposes we shall run the "revision" makefile rule, and modify a few other files.



Below is the status display after making the changes we need:

SVN Status Straight away, we can see there is a marked difference in the status display. Let's take a closer look at what this means.

We have made some changes in the project files, and these files are shown to us by being highlighted in red with their exact status shown in the second column. We can see by the output at the bottom of the window that there are 5 modified files.

All the modified files have their checkboxes already ticked, which means that they are selected and will be included when we proceed with the "commit" operation. If there are any modified files that you do not want to upload to the server, you may un-tick the checkbox for that file, and it will not be committed.

In order to "put" these files back onto the remote server, the second button (the green up arrow) will start the commit operation. Each commit should be accompanied by a "commit message", and it should describe the changes made to this revision. This is very useful to you, and others, if they want to checkout a previous version for testing, as they can view the "commit log" and see what was changed and when. We will see this log in action a bit later on.

SVNBench has a built-in editor for composing the commit message, and it includes a list of the files that will be committed, although this is not included in the message that is saved on the server.

SVN Compose

Here we have added two lines at the top of the message to describe what we have done. The list of files is included below the "tear" line (this line and beyond gets omitted in the message stored on the server).

The contents of the commit messages are very important, and a more in-depth explanation can be found in the "Info" section.

It is possible that you may have made changes to quite a few files, and in order to supply a meaningful commit message, it is helpful to be able to view the changes by using the "diff" feature and note the changes as you view the files. Luckily, you can open this editor window at any time from the popup menu and make notes for each file as you go through them. Once you have viewed all of the files ready for commit, simply press the "commit" button, the editor window will pop to the front, and the button will activate and highlight in bold text.

Once we are happy with our message, we select , and the process of uploading the changed files will begin. If you want to abort, or want to reset the message, select and you will be prompted on how to continue.

So that concludes our overview. We have shown you how to add files to a new project from a SVN repository (checkout), and how to upload any changes back to the remote server (commit). We shall now cover the toolbar buttons and the more advanced functions below.

back to SVNBench

 

 

 


Detailed View

 

So we have seen above how to checkout files, and how to commit them back again. Now we shall take a closer look at the toolbar, and what functions it offers. While this details SVNBench, it is by no means intended to be read as a an exhaustive documentation on the use of SubVersion.

For full documentation on how to use SubVersion, please visit the SubVersion website. We also recommend the SVNBook website at red-bean, who offer HTML and PDF versions of their highly informative book on SVN and its inner workings.

 

SVN Status Button Gather and display the current status of the working copy. (See above)

SVN Commit Button Commit any changed files back to the repository.

SVN Update Button Update the working copy with any newer files from the repository.

SVN Clean Button Try and repair any locks that may occur due to partial commits or updates.



SVN Add Directory Button Add a directory into the working copy.

SVN Add File Button Add a file to the working copy.



SVN Rename File Button Rename the selected files.

SVN Remove File Button Delete the selected files.

SVN Drop File Button Drop the selected files.

SVN Information Button Show information about the currently selected file.

SVN Revert Button Undo the changes to the local file by replacing it with the one from the repository.

SVN Diff Button Show the differences between the file in the working copy and the most recent one in the repository.

SVN Compare Button Open the selected file in "FileCompare".

SVN Blame Button Show the history of changes in a file in the repository by either revision or author.



SVN Checkout Button Checkout a particular revision of the repository.

SVN Preferences Button Open the SVNBench preferences.




SVN Popup Menu The main window also features a popup menu which mirrors many of the above functions available in the toolbar. It also allows other functions for handling files and content.

The first 2 options allow you to specify what to include or exclude from a commit operation, and is useful to work on all the project files, rather than having to manipulate each one in turn.

The next 2 options allow you to expand or collapse any subdirectories that may be in your project.

Many of the following items are just mirrors of the toolbar functions. There are some exceptions which are relative to the file the menu was invoked over, and are described below:

  • Check if an update is required...
    This option will query the repository server to determine whether there are some remote files which need to be updated locally.

  • Diff against revision...
    The toolbars "Diff" button will always check the local file against the most recent file stored on the repository (the "HEAD" revision).
    This option allows you to check the differences between the local file and a "revision" of the remote file. Every time files are committed to the repository, they are stored under a revision number. As the same file may be changed many times during the development cycle, those alterations are saved against the revision number when the file was committed. This way we can check the changes made each time the file was uploaded to the repository.

    So how do we know which revision of the file we would want to check against?

    Diff against revision This is where the Log History comes into play. If you remember back, we talked about how important these messages are, and each revision will match against a message. Using that message to see what changes were made, helps us identify the revision we need.

    As we can see from the dialog here, the commit messages are very descriptive of the changes at each commit. The revisions are listed in latest to earliest, with the top one being the most recent (also known as the HEAD revision).
    As a further aid, double-clicking on any entry in this list will reveal the files that were changed during the committal of this revision, as below. Diff against revision showing files

    There is a toolbar to the right hand side which allows some options concerning the commit log, and as this window is identical in functionality to the "Info" window, we shall discuss what these buttons do later on in that section.

    Once you have selected the revision that you want to check against, the "Diff" window will open exactly the same as a normal "Diff" operation.

back to SVNBench

 

 

 


Toolbar buttons explained

 

 

SVN Status Button Status

This is the default action, and will display all the files in the project directory (and any subdirectories) and list what their current state is. Files that have been recently added, removed or modified will be highlighted in red and have their status listed next the file name. From here, you can get information on files and directories and view the commit log.

back to SVNBench

 

SVN Commit Button Commit

This action will commit all changed files that have their checkboxes ticked back to the remote repository. Each time files are committed, a message should be supplied which details the changes that this revision includes. These commit messages can be read when viewing the log of a file or directory, and helps if you want to checkout a previous version for testing purposes. See the Info button for more information.

During this operation, the changes from your files will be merged with the files on the repository, and any other pending changes too. This is the main strong-point of Version Control Software, and it is this ability to track the changes that makes the system so versatile.

back to SVNBench

 

SVN Update Button Update

While committing your changes back to the repository to allow other users access to them, this allows you access to changes from other users by updating your working copy from the repository. Once the Update has started, this will download any files from the repository that are newer than the files in your working copy. By updating regularly, you ensure that you are always using the latest versions of the source code files. CodeBench will automatically prompt you to perform an update when loading a project that has not been updated for at least 7 days. This action will also replace any files which are deemed as "lost". If a file in the working copy gets deleted, accidentally or on purpose, then Update will replace it with what is currently stored in the repository.

If you have changed files in your working copy, the SVN client will attempt to merge these changes with the file being updated, creating a hybrid of the remote changes and your own. While this functionality is very powerful, it may not succeed if there are too many changes or the changes are too extensive. In this case, the status of the file will be set to "<Conflict>", and you will need to merge your changes manually with the newly updated file. There may be a file placed in your project directory that shows where the conflicts are, and this may make the merging job easier. Basically, follow the golden rule of "Commit often" and you should never see a file with a "<Conflict>" status.

back to SVNBench

 

SVN Clean Button Cleanup

Because you are dealing with files over the internet, it is always possible that something may occur during a transfer which can interrupt or truncate a file. If this happens, it is likely that you will end up with some files that are "Locked". This option scans the working copy and tries to repair any faulty files that it finds. If a file is seriously corrupted and cannot be repaired, sometimes deleting the corrupted file from the project directory and performing an Update operation will restore it. NOTE: This involves deleting the file from DOS, not via a Remove operation from SVNBench. If the file is not found locally, it will be replaced when updating, but a Delete will remove the file from the repository as well, which really isn't what we want.

back to SVNBench

 

SVN Add Directory Button MkDir

SVN Make Directory Button During the life of your project, you may want to add a subdirectory in which to put some more files and better organise it. You will be prompted to enter the name of the directory. The button will cancel this operation, while the button will add the directory with the name you entered.

You will be prompted for a Commit message to go along with this new directory. This is optional, and generally does not need explaining, but it can be helpful when reviewing the logs, as can be seen here.

If you perform a Status operation, you will see the new directory listed with its state as "<Added>". In order to add this directory to the repository as well as the working copy, you need to commit this change. Then, and only then, will other users see this change. When they perform an update, the directory will be automatically added to their working copies too.

back to SVNBench

 

SVN Add File Button Add

You may want to add files to the new directory you have just created, or perhaps just in the project directory.

There are two ways to add files, the first is to select this option without highlighting any files in the Status list. This will then open a standard file requester where you may choose the files you want to add to the working copy.

The second way is to select from the ghosted items in the list. We briefly discussed these files in the overview, and these files are marked as "<Not in repository>". What this means is that although they are listed in the project directory, they are not actually part of the working copy. There may be numerous reasons for this, and typically items like personal configuration files would not be included in a repository which multiple users access. Lets assume you have created a new source file, and you have run the Status operation on the project. Your new file is shown as ghosted, so in order to add it, select it by clicking the mouse over it in the list, and click the SVN Add File Button button. You will see the output from the SVN client as the file is added. You can select multiple files to add, both from the list and from the file requester, but only files that are not already added will be processed.

Again, just like MkDir, once files have been added to the working copy, these need to be committed in order to upload the changes back to the server. Once you do that, other users will automatically receive the new file when they perform an update.

back to SVNBench

 

SVN Remove File Button Delete

While you can add files to the working copy, you can also remove them too. Select the files you wish to remove from the Status list by clicking the mouse over the file name, and the SVN Remove File Button button becomes active. Click the SVN Remove File Button button to start the process of removing files. You may remove only files that are part of the working copy (and ultimately the repository). You will see the output from the SVN client as the files are removed. This is both a local and remote operation, the file will be deleted for ALL users, including you!

A Commit operation must be performed to permanently remove these files from the repository. When other users of the repository perform an update, these files will be automatically removed from their working copies too.

One point to note here, is that the file is not really deleted, as it still exists in previous revisions.

Let's imagine for a moment, that file "blah" was removed in revision 100. All other repository users will have that file removed from their working copies too when they update to revision 100.
Now consider that someone checks out revision 99: "blah" would be restored in the working copy because it was part of the repository under that revision.

Once files are added, they can never truly be removed again.

back to SVNBench

 

SVN Drop Button Drop

This is not a standard SVN operation, but one that SVNBench implements itself. It works in a similar manner to the Delete operation, but with the exception that a local copy of the file being dropped is left in the project directory. After performing a Status operation, you will see the file listed but no longer part of the working copy.

A Commit operation is required for this action to become permanent. Other users will have the file deleted when performing an update.

back to SVNBench

 

SVN Information Button Info

View information about files and directories in the current working copy.

SVN Revert Button Revert

This option is useful for programmers that want to experiment with the code, or for when testing particular code sections. Let's take our example above and select all the files that have changed by clicking them with the mouse (you will need to hold down the shift key to select multiple files). With all 5 files selected, click the revert button and these files will be replaced by the versions stored on the remote server. This effectively removes the changes we have made, and is useful when testing different scenarios in the code, and then resetting the code after the testing has finished. Obviously, the changes you have made will be lost. There is no need to Commit after this operation has completed, as you have only downloaded and replaced files, no remote changes have occurred.

back to SVNBench

 

SNV Diff Button Diff

Differences between two files It may sometimes be appropriate to view the differences between a file in the working copy and one stored on the remote server. This is what the Diff operation is for. From here you can view where the changes in a file have occurred. This may help ascertain whether a changed file should be committed or reverted.

In our example project above, we have made some changes to the "Makefile" file. Selecting that file in the list, and selecting this option opens the "Diff" window.

There are 3 panels in which various information is shown.

Firstly, the "Changes" section shows all the sections of the file that has been changed, and allows you to jump to a specific area for easy viewing. As you move the cursor from line to line in the "working copy" panel, the highlighted item in the list may switch from one to another. This works exactly like the "Quick-Link" window and shows you in which section the text cursor is currently placed.

The "Working copy" panel shows the local file in its entirety. Changed lines reported by the SVN client are highlighted in red, but typically the changes are bordered by a few lines at the top and bottom. There are also some small graphical symbols which show you what kind of change has been made. A "+" symbol means a line was added, and a "-" symbol means a line was taken away. Lines highlighted in yellow are the bordering areas reported by the SVN client and have not been modified.

Lastly, the "Original section" panel shows what the corresponding text looks like in the stored file on the repository. Placing the cursor in a highlighted section of the "Working copy" will show the associated block here, and this allows a quick and easy view of the changes that have been made to a specific section of the file.

You may select multiple files from the list to view the differences of, and each one will be added as a separate file, each with its own "tab", making it easy to switch between files for comparison.

You may also select more files from the main SVN window and select this option to add them without the need to close the "Diff" view. A new "tab" will be created for each file added.

Using this function from the toolbar will always perform the operation against the latest revision stored on the server (the "HEAD" revision), but there may be times where it may be useful to check against a different revision. This is possible by using the "Diff against revision" item from the popup menu.

back to SVNBench


Compare Button Compare

back to SVNBench

Blame Button Blame

Despite its name, this feature can be very useful when trying to revert changes in a file in the repository. It will allow you to see what changes were made to a particular file, and in what revision those changes were made. This feature gets its name because it will also show you those changes and who made them.

Select a file in the main list, and you should see the Blame button highlight (You may also select multiple files from the list, and those files that are applicable will be added to the Blame window). Only files that are part of the repository and subsequently in the working copy can be viewed, and those files must have been committed back to the repository. It is not possible to use this feature on modified files, and a requester will display this warning.

To illustrate the various different revisions and authors, we have selected a file which is part of the OpenAmiga "Filer" project.

svnblame1 In the list on the left hand side, we can see all the different revisions that this file has undergone. By selecting one of these, the source of the file on the right will have all the affected lines highlighted. A brief description will be shown in the status bar under the text, and this will show who committed the revision, and how many changes were made.

The chooser gadget above the list will allow you to switch to the different users that have committed revisions too. Again the status bar will show how many changes were made, except this time the amount of changes is a total amount made in all revisions committed by the selected author.

This makes it very easy to tell what changes were made and when or by whom, hence the functions name.

 

SVN Blame2 In this view, we have switched the list to show the authors that have committed changes to this file. We have selected the user "Rigo", and the status bar shows us that there have been a total of 5 changes committed by this author in all of the revisions submitted by this user. All the affected lines are now highlighted in green to make it easier to see which lines are changed.
Apart from scrolling through the entire file to locate the changes, if you right-click the mouse over the source code, a popup menu will be presented.
SVN Blame popup menu The first two items enable navigation of these changes.

The next is a little different. You will notice the line number is present, and is the line the cursor is currently on. You can place the cursor on any line of interest and envoke the menu, and this item will always apply to that line. What this will do, is to locate the last time this line was changed. The revision or author will be highlighted in the list on the left hand side, and the changes that apply to that author or revision will be shown.
So not only is this useful to find out who last changed any line, but also what other changes were made at the same time, as shown in the status bar at the bottom.

If you hover the mouse pointer over any of the revisions or authors in the left hand list, the help hint will show various information pertaining to that entry in the list. This allows you to see what changes will be highlighted if you select this item.

Just like the "Diff" window, you can use this window and the main window at the same time, and add more files to it as you require. Closing the main window will also close this window automatically.

back to SVNBench

 

SVN Checkout Button Checkout

This option can have two modes of operation.

The first is to download the code from a repository into a clean directory on the local machine. This will inevitably download the latest revision of the repository.

Choose Revision The second mode is to download a complete revision of the repository, which may not necessarily be the latest. This is sometimes required if the changes made to the latest revision are problematic, downloading an older revision that doesn't have those changes can help to see why the problem might occur. Of course, the log history may also come into play here providing the commit messages are detailed enough.

As you can see from our above overview, when SVNBench is run for the first time with an empty project directory, you will have the opportunity to checkout the latest revision of a repository. You will need to know the URL (internet location) of it, and also any login details required.

Once you have checked out some code, selecting the Checkout operation again will then open a requester which will list all of the revisions currently in the repository. You may select one of these revisions by clicking it with the mouse, and selecting the button. If there are any outstanding changes to the working copy, you will be notified of this, and given the option to cancel the checkout. Once the operation has finished, the working copy will be synchronised at the version you selected, and this will include adding or removing files and directories as required. This is why committing your changes back to the repository is so important, especially when working in a group, and helps to cut down the chances of a failed merge. Any changes made prior to the Checkout operation will be lost unless they are committed first.

back to SVNBench

 

SVN Preferences Button Preferences

URL preferences This requester is very basic, and only has a few groups of settings.

The first group is the location of the repository to which this working copy should mirror. It also allows for any login details to be entered (if required). NOTE: These settings are only editable when initially creating the working copy. Once created, these details are for informational purposes only, as changing the URL of the repository can have consequential effects on the files stored.

The second group of settings simply allow you to set the location of the SVN client, and is covered in more detail above.

The Directories tab allows you to change the directory from which Commits and Updates (Put and Get respectively) are performed. You may be wondering why that might be useful...

Let us imagine that your current project is actually part of something larger, and buried in a subdirectory of the entire project hierarchy. A good example of this might be a program that has a library. The program may well be treated as a project in its own right, and the library also. Normally this wouldn't be a problem, but the possibility is that some common files may be changed while working on the library, but the programs project would not see those changes as these files are outside it's home directory.
By changing the directory to perform put and get operations, we can allow the Subversion client to do its work from a directory higher up in the tree where the common files will get updated. Imagine if you will:

Trunk <dir>
Program <dir>
Library <dir>
Include <dir>

If we try to perform a commit operation from the "Program" directory, any changed files in the "Include" directory will not be sent to the repository, so by changing our "Commit Directory" path to the "Trunk" directory will mean any changed files will be sent to the repository and thus nothing gets missed. Similarly, performing an update from the "Library" directory would mean that the changed files in "Include" would not be updated, and vital changed could be missed.

Although the two directory settings are treated separately, they are equally applicable, and as such you should probably set them both to the same higher directory to be sure nothing is missed.

back to SVNBench

 

 

 


Information Window



SVN Information Window From here you can view certain information about the selected file or directory. Here we are showing the information known about the project directory. As you can see, the upper portion shows the static information, and the lower part the details of when the last change was made.

As we discussed above, the Log is probably the most important part of this information. That does depend, however, on the quality of the commit messages. For those of you that work as a single programmer on a project, this is perhaps not so vital, whereas those that work in groups will find the Log History essential in tracking what changes happened and when.

Every time changes are submitted back to the repository (committed), a "revision" is created by the repository server. This revision is a snapshot of all the files in the repository and their state at the time of the commit. With this in mind, let's consider just one file in the repository, and how revisions effect that file.

It all starts with the initial commit (usually when the repository is created or the file is added). At this revision the files contents will be at a certain stage. As development continues, the contents of that file will change over time, and each time the file is committed back to the repository, the files contents are recorded and logged under the revision number at the time. So by looking at the same file, but at different revisions, we can see the history of the changes made in that file.

Now multiply that by, potentially, hundreds of files. It all makes a rather large mess to try and sift through.

Each commit is accompanied by a commit "message". If each message described in easy to understand terms what was changed and why in that revision, it would definitely make it easier to track those changes.

This is where the Log History comes into play.

The information window is divided up into two "pages". We have already seen the "Information" section above, but the second tab shows us the history of changes,, known as the "Log History"

SVN Log Here is the Log History for the project directory. The list is ordered by revision, with the most recent (known as the HEAD revision) at the top. Each revision is accompanied by the message that was given for each commit.

Here we are viewing the history for the project directory, but we could just as easily view the log for one of the files in the project. As the list would only include revisions where that particular file changed, this allows us to narrow down the list of possible revisions that could be of interest.

As we are viewing history for a directory which contains multiple files, how can we know which files actually changed with which revision?

By now, you may have noticed a small toolbar on the right-hand side. Here we can find various functions we can perform on the log or an entry in it.
The one we are interested in right now is the SVN Log Info button button which allows us to view just which files were changed in this revision.

Select a revision in the list and this button will become active. Clicking it will open a new list showing all the files that were changed. You can also double-click an entry in the log to open and close the same list. Clicking the button again will also close the list. SVN Log with changed files

So now we can see each revision, we can read the commit message describing what changes were applied to a particular revision, and we can even view exactly which files changed in any one revision.

All this information is also available when selecting a revision to, for example, check out, or view differences of.

All in all, the Log History is an extremely useful tool to determine what, when and how.

It certainly isn't every day you would need this feature, but when you do, it should definitely help to decide the best course of action when you need to access previous versions of files.



back to SVNBench


Information Window Toolbar



Search log button

Search the log for a particular string. Each commit message that contains the string will be highlighted in the list, and the first match will be shown automatically. The amount of matches will be listed in the status bar at the bottom of the list.

View changed files button

Show or hide the files that were changed in this revision.

Edit log message button

Edit the message for this revision.
Note Not all servers will allow users to edit log messages after they have been committed.

Copy log message button

Copy the log message to the clipboard (unit 0).
You may wish to use this message text in another application, or edit it and use it again. In any case, clicking this button will copy the commit message to the clipboard for you.

back to SVNBench

SVNBrowser



Like with all plugins available to use from inside CodeBench, this plugin makes handling repositories much easier than command-line tools, like "svn" etc.
Unlike other plugins, the "SVNBench" plugin CAN be used from anywhere with the use of SVNBrowser.

This tool can be found in the "Utilities" directory in your CodeBench installation, and allows you to access any "working copy" you might have on your computer.

Simply run it and choose any svn controlled directory, and it will give you all the benefits of the graphical nature supplied by this plugin, but completely outside of CodeBench. You can also run SVNBrowser with the path to a working copy as an argument, and this directory will automatically be used. This saves having to choose if you run it from an environment where arguments can be passed.

This makes it an ideal companion to any application where you can assign a command to a button, like "Filer" or "Directory Opus", for example. You could even assign it as an "App-Link" in the IconBar of CodeBench itself, the choice is yours.

back to SVNBench


Valid XHTML 1.0 Transitional This is a W3C checked and compliant web page.