Click the menu item to create a new request.
Click the request hyperlink when viewing a grid of requests. This is found in many places.
This will take you to the edit request wizard where you will follow the steps to create or edit a request.
First step is to select a Project / Branch. Requests are always created or built in the context of a branch.
Here we will select the 3.3 branch for the Northwind project.
The second step is to set filters. Filter settings will be remembered until they are changed. Filters are important because they can increase performance and make it a lot easier to select the correct files and not miss files that should be selected.
There are 2 types of filters, an "Author" filter and a "Last Updated" filter. For each filter you can set the action to - "None", "Filter" or "Change Font". If the action is "Filter" then the files that do not meet that filter are filtered out and will not show in the list of files to select from. So if you set an Author filter to your user id, only the files that you checked in will be visible.
If the action you select for a filter is "Change Font", then you will be prompted with a font selector as seen below. So in our example, we will filtering out files that were not checked in by "JBrooks" and we will change the font to blue and bold for the files that were last updated after 2/1/2010.
Another important option is the check box - "Only show files changed since this branch was created." This allows us to filter out any files that were not changed in the branch that we are making a request for.
You can have as many Author Filters and Update Filters, all will be applied to the files listed in the next step of the Request Creation Wizard.
In the "Files" step of the wizard you will be selecting the files that you want to be built with the request you are editing. You may not need to do this often if you use the optional TortoiseSVN Client Plugin.
First thing to note is that the filters defined in the previous step were applied. So in this example we are only show files that were updated after the 3.3 branch was created and files that were updated by "JBrooks". The files updated after 2/1/2010 are shown in blue and bold.
Expand All Mode checkbox. This checkbox is used to control what happens when a folder is expanded. So if this checkbox is not checked and I expand a folder - only that folder is opened. If this checkbox is checked, the folder I expand is opened and so is all of it's children folders.
Match Author by looking at last checkin only checkbox. When you have an Author Filter that changes the font for matching authors and this checkbox is checked, only the last checkin author for each file is evaluated to see if there is a match. If this checkbox is not checked then every checkin since the branch was created is evaluated, and if a matching author is found it is counted as a match. You would have this checkbox checked to gain a performance improvement.
COLUMNS
You can click any of the column headings and the rows will sort by that column - within a folder. This can help you in finding the files you want to include.
Files - Everything from the branch on down (in this case the "3.3"), is pulled from your Subversion repository. So for the most part, you are looking at the hierarchy of folders and files as they are in Subversion. You can expand the folders and show the files in them by clicking the plus sign next to the folder name. This example actually pulls from 2 branches both named "3.3". One is for database code and one is for front-end code. Note that there is a check box next to each of the files, if this is checked then the file will be included in the request.
DateTime - This is usually the last Subversion commit date and time. If the request was created with the TortoiseSVN Plug-in then it is the date and time the TortoiseSVN commit was done. This can be different than the Subversion date and time.
LastUser - The last user to commit changes for this file.
Version - The version or revision that the file was in when the request was made. See the LockVersion column for more information.
Current Version - The current version or revision for this file in Subversion.
LockVersion - When a file is included in a request and later a new version of that file is committed to the branch, then by default the new version is what is built. You are given the ablility to override this default behavior. If you click the Version number for a file, you will see a list box that will show all of the version for that file since the branch was created.
The list contains a line for each of the commit versions (or revision) for that file. Each line has the datetime, the user, the revision number and the comment for that commit. If you select the last item, which is blank, then it clears that fact that you are selecting a specific version and it will go back to the default of taking the latest version in the branch.
If file is locked to a version then the version that it is locked to is shown in bold in the Version column, the CurrentVersion column is populated with the current version and the Locked checkbox is checked. In the example below we locked the file dbo.Orders.sql to version 158.
BuildOrder - Note that you usually do not need to define a BuildOrder under normal circumstances. When you do a build, the SQL files are built in order based on the folder that they are in as defined in the section Build Folder Sort Order.
Here we see that "table" is the second folder that will be built. Within a folder files will be built in alphabetical order unless you override that order using the BuildOrder column when you are creating the request.
Below we specify the BuildOrder to control the order that the files will be built. Here the files will be built in the order of -200, -100, 1, 2. Any file that does not have a BuildOrder defined will default to zero.
You can always sort by the BuildOrder column to easily see the order that the files will be built in.
Issue IDs - The forth setup in creating or editing a release request is the step where you assign the issue IDs to the request. Here you are linking the file changes selected in the previous step to the issue IDs in your issue tracking system.
This list is pulled from your issue tracking system. When you setup the project you entered the connection string and SQL that is now being used to make this list. The Release Manager just adds the first column "Include" to allow the user to select the issues.
As part of our SQL we usually include a WHERE clause to narrow down the list the user sees to only include issues for the current project and branch that are assigned to their user id. So the were clause for our issue tracker usually looks something like:
The place holders %p, %u and %b get valued with the current request's values. So 'Northwind', 'JBrooks' and '3.3' in this example.
The user has the ablity to click the "Other Issue Item" button and enter any issue ID they want. This is done to assign an issue ID to the request that isn't assigned to their user id or version (branch), or any other reason it might not be in the list.
If you later reedit the request, you will see that issue ID 2022 is included in the list of issues even if it doesn't match most of the WHERE clause. This is because of the part of the WHERE clause that looks like "OR IssueId in ({0})". The {0} will be populated with the previously selected Issue Ids, so in our example "(1924, 1954, 2022)". This insures they are included even if they no longer match the othr parts of the WHERE clause.
Notice that the last item is Issue ID 2022 and it is included even though its release number (or branch) is 4.0. In this example, that issue should be change in the issue tracker to reflect that it will be addressed in release 3.3.
Header - the next step in creating or editing a request is to give the request a name and to indicate if there are any special build instructions. It is not common to need to include special build instructions, but if needed this will be visible to the person that will be selecting the release requests while creating a build. Special build instructions might be the fact that an IIS reset needs to be done or a new prerequisites such as a framework version that might need to be installed.
Summary - the final step in creating or editing a request is the summary step. Here you review your list of files and click the "Submit" button to save your changes. Nothing is saved to the database until the "Submit" button is clicked.
