Subversion Tip of the Week

Using an Editor for Entering Log Messages from Command Line

When you are using Apache Subversion from the command line, whether from Windows or UNIX, it is possible to have an editor pop-up and enter the required Log Message.

There are three methods for getting the Log Message into Subversion.

1) Use the –message (-m) option and put the message string in quotes.
svn ci –m”Fixed bug # 4322”
2) Use the –file (-F) option and put the message in a file
svn ci –F logtxt.dat
3) Or, have SVN launch an editor and use it to compose your message.

Of these three, the last one is the easiest.

If you do not use any of the above options, you will receive the following message.

Setting up an editor is quite easy. There are two different options.

Use the configuration file or use an environmental variable to point to the editor.

To use the configuration file you need to modify the config file and add the line that tells Subversion to use an external editor.

### Section for configuring external helper applications.

[helpers]

### Set editor-cmd to the command used to invoke your text editor.
### This will override the environment variables that Subversion
### examines by default to find this information ($EDITOR, et al).

editor-cmd = notepad.exe

To use the environmental variable, set the EDITOR variable to your editor. In the command window, execute the following line.

set EDITOR=notepad.exe

You can use any editor that can be initiated from the command line. I have used both Notepad and TextPad.

Below, I show the screen that comes up in Notepad, then the screen filled out with my comments, then running the Log Command to see the new log message.

This is the screen that pops-up when using notepad.exe. The existing text tells you the file(s) modified and where to add the Log Message.

Here I have added in the Log Message. After this save the file, then exit the editor.

Here I ran the “LOG” command to see the new Log Message. Note: The extra lines in the editor were purged.

If you exit your editor without saving its contents, you will receive the following message.

The options are:
(a)bort – Cancel the COMMIT command.
(c)ontinue-Finish the commit with no Log Message.
(e)dit-Bring the editor back.

Mike Lester is WANdisco’s Director of Training. Mike has more than 33 years of experience in the software industry, having spent the past 26 years focusing on training and consulting for Subversion and other software configuration management systems. Mike delivers WANdisco’s free training webinars, and regularly shares his SVN know-how at the WANdisco blog. Mike is also available for Enterprise Training.

Subversion Tip of the Week

Structuring Your Repository

Implementing a logical project layout in Apache Subversion right from the beginning, can save you from administrative hell later. Here are some general rules worth bearing in mind when creating a new Subversion repository, to ensure all that freedom doesn’t lead to complications.

  • The code in the trunk should be stable – all experimental development should be confined to separate branches.
  • Consider continuous integration and automated regression testing – these can help ensure there is no regression in the all-important trunk. uberSVN users can download the popular Jenkins open source CI server for free from inside their installation.

    • Make snapshots of your project – tags should be used to make snapshots of your project at certain points during the development process (e.g. tagging a snapshot as ‘Release 1.0.’) It is also good practice to make snapshots of your project before implementing major new features. This makes it easier to roll back and effectively ‘undo’ the new feature, if required.
    • Take care when making structural changes – structural changes should always be performed on the trunk, when there are no branches waiting to be merged. This can help development teams avoid serious and time-consuming conflicts.

    Mike Lester is WANdisco’s Director of Training. Mike has more than 33 years of experience in the software industry, having spent the past 26 years focusing on training and consulting for Subversion and other software configuration management systems. Mike delivers WANdisco’s free training webinars, and regularly shares his SVN know-how at the WANdisco blog. Mike is also available for Enterprise Training.

Subversion Tip of the Week

Filtering Log Messages

When you have 40-50 revisions and a couple of projects, finding a particular revision is pretty easy. When you have three years of history, 20 active projects and revisions in the high five or low six digits, locating a specific revision can be an adventure. (And by adventure we’re not talking about a trip to Disneyland, we’re talking about the running out of gas 20 miles from the nearest town in 2 feet of snow, at night, type of adventure.)

First of all, finding a specific revision becomes a lot easier if you have some standards:

  • Always put in log messages. Not just for commits, but for copies, deletes, renames, anytime you are prompted for one.
  • For certain activities, have a defined structure. “Fixed bug #1431”, “Added Feature #5r31a”, “Created Branch”, “Deleted Branch”.
  • Use training, published “Policies and Procedures”, hook scripts and active management to ensure that proper log messages are added.

Luckily in TortoiseSVN you can filter (search) for log messages. In fact, you can search for log messages as well as the text of authors, dates, and paths. But mostly you will search on log messages.

Let’s look at an example of filtering. In the picture below we have a standard of entering the log message “Working on Bug #nnnn” or “Fixed Bug #nnnn” depending on whether the development effort is underway or finished. The first image shows our results, pre-filter and the second picture shows filtering on the bug number “5100”.
Log messages with no filtering.

Filtering on the string “5100”.

But let’s say we want only those revisions with the bug number “5100” but not containing the string “Working”. This would give us the revision where the bug was fixed.

The filter “ 5100 -Working” would look for all messages containing the string “5100” but NOT the string “Working”.

The minus sign (-) means without.

Note: The filter “5100 -WoRkIng“ would generate the same results. Case is ignored.

Other examples of filtering:

  • Sort -Marketing +Finance – searches for strings containing both Sort but not Marketing, or strings which contain Finance.
  • !Sort Report – searches for strings which do not contain both Sort and Report
  • “Finance Reporting” – searches for the literal expression “Finance Reporting”

You can also use regular expressions to limit your searches by selecting this option. An example of a regular expression would be:

  • Market(ing|ers) – which would find messages with Marketing or Marketers.

But that will be covered in another blog.

Subversion Tip of the Week

The “Import in Place” Procedure

I have a large project that has lots of folders, and I only want half of them to be imported into Apache Subversion. What do I do?

The solution to your problem is something called “Import in Place”. WANdisco covers this topic as part of the Subversion User Class.

So here is our situation:

We have some development that is not yet part of Subversion.

As development evolved, a number of folders have been created for numerous reasons, that all have the same characteristic. We don’t need their contents under version control. The information could be simply unneeded or should not be seen for some reason. (Privacy, legal, embarrassing.)

We are experienced enough to know that importing all the folders and then deleting the ones we don’t want is not a great solution. (a.) The wasted storage still takes place or (b.) Anyone could view the contents by looking at the earlier version of this project.

We could manually import all the needed folders one-by-one but that might take a lot of time or effort or more importantly, result in accidentally skipping one or more folders.

Here are the steps:

  • Create your top level folder in the repository. (In this example the repository is “inplaceDemo” and the project is “BankDocSystem” and our top level is the trunk folder.)

  • Checkout the top level to the folder that holds your current development code. (See Figure 1) You will get a warning that the local folder is not empty. Now you have a versioned top level folder with unversioned content.

  • Use the ‘TortoiseSVN Add’ command on this folder.

  • Uncheck the files/folders you do not want to be part of version control, or unselect all the boxes and then select the files/folders you want.

  • Perform the commit command.

  • Look in the repository browser for your populated project.

This technique can save a lot of time and hopefully a few errors.

Subversion Tip of the Week

The Oops Command

Often when you are changing code, you will realize that you have meandered down the wrong coding path. You can take the manual approach and try to back out of your changes but Apache Subversion gives us an easier way. It is called the revert command.

If you want to have a file restored to where it was when you last checked it out, or when it was last updated, you can use the revert command to restore a file (or files). This command will appear in the context menu from your working folder if any files have been changed. Be aware that if you select a changed file and then right-click, you will only be reverting that file (or files) you have selected. To make sure you will be affecting all the files that have been modified, either right click on the top of the working folder or make sure you have selected (using the Ctrl/Key) all the files you may want to convert.

Below is an example of the first step of the revert command. Here you can decide which files to revert and which to ignore.

You can check the box of any file you may want to revert to what it looked like when it was checked out or updated. Be aware that both a files’ changes and any changed Subversion properties will be changed by the revert command.

At the bottom of the form there is a button labeled “Delete unversioned items…” This will present you with a form where any files that you have added since doing a checkout (but not added with the Subversion ADD Command) can be selected, and then deleted.

The revert command also works with folder changes. Below you see the effect of running the revert command after adding a new folder (“newfolder”) and renaming a folder (“reports” was renamed to “User_reports_renamed”).

The effect of a rename shows up as the deletion of the old folders and addition of the new (renamed) folder.

Every week WANdisco’s Head of Training Mike Lester will publish a tip to help you get the most out of Apache Subversion. Mike also delivers free, bi-weekly training webinars on topics ranging from branching and merging best practices, to Subversion in the enterprise, and advice on making Subversion agile. Register early, to avoid missing out! Enterprise Training is also available.

Where Did That Branch Go?

When teaching “Subversion User” classes, one of the frequently asked questions is “When do you delete a branch?”

Unfortunately the reason they are asking about deleting branches is because they are concerned with saving space. And as all experienced SVNers know, deleting will have no effect on repository size. Remember, when anything is deleted in Subversion, whether it is a project (folder), a file or a property, it is only deleted in the revision where it is deleted, and subsequent revisions. It still exists in all previous revisions and can be viewed or recovered at any time.

So the question remains. “When, or why would you ever delete a project?”

First let’s look at the cases when you would NEVER delete a branch:

1) Some branches are always needed such as the “trunk” or branches that contain other branches like the folders “tags”, and “branches”. This assumes you are using the TTB layout format.
2) Some branches are referenced frequently. The branches in the “tags” folders that hold your recently released versions are used to create releasable code and compare to current trunk development efforts repeatedly.
3) Branches where concurrent development is taking place. Before the branch is merged back to the trunk (or wherever it was branched from) it would be confusing to delete the branch. It might also lead to someone forgetting to do the merge.

So that leaves us with the following types of branches that MAY be candidates for deletion.

1) Abandoned work efforts. For example, you may start a branch to do concurrent development, and later decide to do the work in the trunk. What do you do with the abandoned branch?
2) Branches that represent old versions of your code. Let’s be realistic, if you are on Release 5.6.004 you may go back to Release 5.6.003 or Release 5.5.012. But how likely is it you are going to need to reference Release 1.0.01 from 4 years ago.
3) Mistakes created when using the COPY command. You meant to create a Release branch from revision 1255 of the trunk and you mistakenly selected the revision 1250.

All three of these are good examples of when you might do a deletion. But if you are going to do a deletion you should have some rules. And these rules should be part of your organization’s “Policies and Procedures”. (We actually spend considerable time in the “WANdisco Subversion Administration Class” talking about the contents and importance of Subversion Policies and procedures.)

Rule 1) Always use the log message to document that a deletion has been done and why. There is a new TortoiseSVN property (tsvn:logtemplatedelete) that provides your users with a template of the information you might want them to fill out. To see a demonstration of this property in use, see this short video. http://www.youtube.com/watch?v=foNQME4rcVQ

Rule 2) (optional) Instead of deleting folders, move them to a folder called “Deleted”. This makes the “deleted” branches/folders easier to find and recover.
Rule 3) Make sure everyone knows how to restore deleted folders/branches.

The best reason to delete any file or folder from a Subversion project is to make the viewing of the rest of the project easier. The less information you have to look at, the more likely you WON’T checkout a branch incorrectly or use the difference command with the wrong branch. Both of these actions might waste your time or create some sort of error that could go unnoticed.

avatar

About mlester