Help Board
From Fortis
Contents |
SVN BLAME
Lesson in tracking changes using svn blame
Q: I'm looking at a diff for earlier revisions in the code where I made changes. As far as I knew, they were still in the code, but when I look in Visual Studio, the code is changed (fixed). Any ideas as to why that is?
A: Yes ... I made some revisions to your commit in a subsequent commit. You are looking at revision 896, where you had made some changes that you thought are still present. When you look they aren't there. The thing to do is to use "svn blame" to find out when it changed to its current state.
Structure of svn blame
From the brontosaurus directory, you would type:
svn blame src/fortis_src/fortis-logic/winframe.cpp | less -S.
This should show you every line from that file, with a number and an author name before it. The number is the revision number at which that line was last changed, and the author is the one who made the change. After you find the revision number for the line you are interested in you can go to the trac website and look up that changeset to see what happened there.
Depending on what you see, you might determine that the reversion/change is accidental and should not have been made, or that it is intentional (more likely) and that there was some reason for putting it that way that also has to be applied with the merge to the appropriate branch.
Blame is a good tool to use any time you notice some discrepancy you want to track down. In some cases, you will see that every line in a file was changed in one revision. This is not very useful. You can add an -r XYZ to the blame command if you want to see what the results would have looked like earlier. If, for example, every line were revised in r912, you could look at r911 to see what changes preceded that one. This would make your blame command take the form;
svn blame -r 911 src/fortis_src/fortis-logic/winframe.cpp | less -S.
In this way, you can track changes by line.
Errors on compile
Resolving duplicate dialog errors
Q: I keep getting "duplicate resource. type:DIALOG, name:165", but I don't know which dialog "165" is. How do I correlate the number with the actual dialog name?
A: The dialogs are numbered based on the resource.h file. The simplest way to find out which dialog goes with which number is listed below (guide by mj).
vi src/resource/resource.h
press j once so that the cursor is on the line that says IDD_ABORTPRINT = 100,
then if you are looking for the number 165 entry, you subtract 100 from that number. what is left is 65
so you type in vi: 65j
and then the cursor will be on the line of some identifier that is number 165
press :q to exit vi.
Alternatively you can open src/resource/resource.h in a text editor such as Notepad++, search for "IDD_ABORTPRINT = 100" and then count the line number to find out which is the offending dialog.
Manually Invoking Filters
How to invoke a filter from the command line
Q: I am unable to export a file. How can I verify that the source document is able to export?
A: First, desegment the file. If you have trouble doing that in Fortis, open the source .fff file in WinVi or similar and remove all segment markers. Within WinVi, a command such as :%s/search_regex/replace_regex/g will remove the segment markers according to your regular expression.
At this point, copy the desegmented source file and the .cod file into the Fortis/bin directory, where somefilter.exe is. In cygwin, navigate to the fortis/bin directory. You can acess the usage help file for a filter by typing ./somefilter.exe
Follow the instructions in the usage help and you should export a working file. If the source export fails, then there is likely a problem in the source document that is causing the translated document to fail. If it exports correctly, repeat the process with the target document. Failed exports will reveal the position of the errors and lead you to the solution.
Troublesome Exports
Look first at tags being misplaced, or text in between tags where they ought not to be. Rearrange the text and tags in necessary. If it still won't work, look for spaces in between tags. Compare it to the source file.
Submitting A New Build to the Update Server
In the root directory of each branch, there is a root Makefile. The root Makefile contains the Major and Minor version numbers of the branch in question. The Major version number should remain the same, but the Minor Version number must be manually updated; incremented by one. A script in the Makefile will check the revision number on your computer against the latest revision in the repository, to verify that you are building the latest revision of a branch.
Back in the root branch directory run the 'make build' command. At the end of the build process, you will be prompted to enter two passwords. This allows the build to be uploaded onto both the update server and the production server.
With the files added to their respective servers, you are ready to update them on the server. Log onto the jellyfish server. You will need to navigate to var/www/fortis/production. From there execute ./addnewbuild.sh. This will display the proper syntax to enter the files you wish to load. Add the new build according to those instructions.
Next navigate to var/www/fortis/(branch). Execute ./addnewupdate.sh to see the syntax for loading the latest files to the update server. Follow those instructions to load an update.
In the production and branch directories on jellyfish server, you should see a HEAD file. You may check that you have updated properly by checking the version number within that file. It will match the version that was most recently added.