One of the snippets of advice in the Neal Ford's Productive Programmer (reviewed here) was to use the Selenium firefox plugin to speed up repetative testing processes

To paraphrase Neal Ford....

So imagine a wizard like set of screens and you are testing step 3, you have to repeatedly fillout the forms for steps 1 and 2 to see the latest change you have made for step3.
With each change and test you think - 'ah just one more change and I'll be done....' ten changes later you are still working on this!

I found myself in just such a loop and eventually downloaded and installed the Selenium plugin to firefox and created a macro to run through steps 1 and 2.

No setup is required. You will find the plugin under the tools menu and it opens a popup window already in 'record' mode for the current site you have open. Go through the screens as normal and Selenium records all clicks and key strokes.

Next time you need to test just click on play in the Selenium popup window.

This was a really big time saver - I wish I had done it right from the start!

This is coming up for us and just wondered if anyone out there has already done this and has any pointers, gotchas, tips, tricks or anything else to contribute to our happiness.

I understand that SVN 1.5 is a fairly major release which incorporates new merging facilities.

We will also need to update the eclipse plugin 'subclipse' that we use to a compatible version. I have started looking at the version we need but think just the latest (1.4.5) will work best. Currently we are using 1.2.4 because we are pointing to our pre 1.5 repository.

If you are working on a file in your project in eclipse and for some reason you need to change the contents of that file to be the contents of the same file but a different revision within the repository, then you would think that the Replace with, Branch/Tag or Revision would do what you need.

I find however that the implementation of this function is not quite as expected (and not the same as when using the same function under CVS).

I would expect that the contents of the current revision are replaced with those of the selected revision (just as though you have made these changes by manual editing) and that as a result this file now needs to be committed.

Now this is exactly what happens if you choose the Revison option - that is a revision in the same branch. You are shown a list of revisions and if you right click you can 'Get revision' or 'Get contents' - Get contents replaces your current files contents withe the selected revision contents and leaves your local copy in need of a commit.

If you select a revision from another Branch/Tag then a 'switch' command is run and your local copy is switched to that branch. You will notice that the SVN icon changes to blue. If you team, update this project, your file switches back to the one on your own branch.

Does anyone else think this behavior is incorrect?

Gert announces that Railo joins JBoss.org and therefore Railo is fully open source....

For a proper analysis of this announcement see my colleague Peter's post here

As I've blogged here before, there are two SVN plugins available for eclipse, subclipse or subversive. We started using subclipse because on balance it seemed to have most supporters. So we used that for a few weeks.
I should explain that we use branches extensively in the development process we use and so we also have to merge these branches back to the trunk. The merging facility of our chosen plugin becomes perhaps one of the most vital parts since this is the trickiest operation and you need all the help you can get!
Using CVS (as we did before SVN) the CVS process within eclipse (I won't say plugin because it is part of the core eclipse build) creates a tag of root_branchname when you create the branch and then when you come to merge defaults to merging from that tag to the current HEAD revision. In the currently, SVN requires you to identify the revision number prior to the root of the branch as the source of the merge. This is more fiddly than I would like, with no defaults and every chance of an inexperienced developer getting something wrong.
Finding the source revision was not always straight forward on some machines we had to use tortoisesvn to look this up as subclipse seemed to be unable to list it correctly. Not only do you have to select the source revision in the branch but also the target revision in the trunk. The target revision is 99.9% going to be the HEAD revision of the TRUNK but this is not the default so you have to remember to set that as well. The merge is always carried out, even when there is a conflict. In CVS you had the chance to review and edit conflicts prior to the merge being done.
These issues made me take a second look at subversive. To start with it seemed a better plugin. You can always find the source revision although in principle the same issues of having to get this right remain. When you merge the merge is not carried out rather you get to review each change and copy these over one by one and then mark each merged file using 'mark as merged'. For small merges this works well, but for larger ones or for branches that have lived longer (time apart from the trunk) there may be a lot of changes in any given file - some have happened on the branch and some on the trunk. Here a major subversive flaw appears - the conflict editor view does not distinguish which changes have happened on the branch and which are from the trunk. This is vital to a complex merge, since you want to focus on the branch changes and be able to assume that changes already on the trunk are good (reviewed by someone else). Subversive also had some 'features' related to how you merged folder trees you had to select the folders beneath the top folder rather than the the top folder else it took a very long time to merge. These issues finally drove me back to subclipse. I'm more used to the selection of revision numbers now and my clean install always seems to be able to list the revisions clearly. Best of all the conflict editor clearly colours the changes black for changes on the trunk, blue for branch changes and red for branch changes that conflict.
The next release of SVN promises better merge control from the repository so these issues may all vanish.

We have been using SVN for the last few months, now having been CVS users for about 3 years before that. While SVN is a sensible choice for the future, we are finding a few weaknesses in the current implementation and I will be posting details of these over the next few days.

The first issue is that running apache webdav on windows server 2003 we find that it slowly consumes more and more memory until it runs very slowly and eventually stops other processes running correctly.

We have reduced the thread limit in the hope that it will force apache to create a new process once this limit is reached but it does not seem to do that.

We continue the search for a good solution to this...

We are in the process of switching from CVS to SVN as our source control system. It is nearly four years ago that we first started using CVS and it has served us well. The main two reasons for changing are

• that SVN is an active project that continues to improve and be developed
• that using svn with apache allows much better/granular/easy to administer access control than CVS


There does appear to be a downside and that is simply that the Eclipse plugins are just not quite as sweet as the integrated CVS interface that comes bundled with Eclipse. As I get to grips with it more I will post the main issues here and to the appropriate mailing lists. At least these are active projects which can only improve.

We have a system that has to produce fairly complex personalized documents as output. We produce these as HTML, with the help of CFML of course. We found however that printing these direct could not really be handled by the combination of browser and printer especially as we had different paper sizes and printers to deal with. So we decided to convert the output to PDF and let Acrobat deal with the printing. The actual printing works well and is faster and easier to manage. The problem comes in converting the HTML to PDF. We are running on the latest patched version of CFMX7, but would have upgraded to 8 if this had solved the problems. What we found was that CFDOCUMENT did not correctly honour the CSS in our documents in fact it seemed buggy adding spaces at random to the output. We also tried a tag called CFX_PDF, but this also lacks sufficient CSS support. After trying several tools we settled on ActivePDF which seems to have very good and complete CSS support. Importantly ActivePDF was the only product that properly honoured CSS page breaks. Without this, producing multi-page documents from HTML on different printers on both A4 and Letter size paper is virtually impossible. It seems a great shame that Adobe has NOT produced the best tool for handling PDF in CF. I look forward to more investment from Adobe in this area for future releases.