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.

I have been using fusebox for a few years now and really like it. I have a way of doing things which has become familiar and seems to do the job, but I wonder what other patterns there are. Here is mine.
I have a layout circuit which runs as a globalfuseaction, postprocess. This handles all the basic page stuff - HTML meta tags, linked css files, javascript files and including any constant elements of the page - title, footer, navigation etc. It will also pick up and render the main content generated by other circuits that have run for the current request. The circuit.xml file for this layout circuit will handle any logic to determine alternative layouts if required (such as popup windows or pages for print).
Business logic and database access is in cfcs.
All control of flow should be visible in the circuit files which means I will have some 'if' statements in the XML. Where possible I invoke cfc methods direct from the circuit.xml. I always use XFA's for all exit points from a fuseaction. One of my aims is that you should be able to open up the circuit.xml files only and understand the application at a reasonable level without the need to delve into actual code.

I would love to hear how other people commonly use fusebox.

Just wanted to highlight an interesting post by my colleague Peter, regarding some key advantages offered by Railo, over other CFML engines. Why Railo

As promised in my last entry, a new minor release of cfsftp (1.3.2) is now available to download that returns a query instead of an array when you call the dir method.

Please let me know if there are any issues with other server configurations. My test environment is connecting from windows to a Red Hat Linux server and it seems to work OK, but some users have had issues with other configurations.

Enjoy.