I've just quickly switched from using Tomcat's JSP compiler to using Glassfish V2's JSP compiler, and it seems worth documenting the changes involved and some of the similarities and differences.

Note that I was previously using the Tomcat 5 JSP compiler, and it didn't seem worth upgrading this to Tomcat 6 just in order to ditch it for Glassfish, so this isn't a like-for-like comparison - some of the fixes/changes noted might also be present in Tomcat 6.

The actual change-over was relatively painless. It's basically the same JSP compiler - which I understand is known as "Apache Jasper 2" - so the general nature of it and the options available are essentially the same.

In Tomcat this is provided via a "JspC" Ant task, and needs to be supplied with a classpath that includes the relevant Tomcat libraries. In contrast, Glassfish provides a "jspc" script that supplies the appropriate classpath and invokes Glassfish's JSP compiler, passing it any supplied command-line arguments.

So switching over basically just consisted of taking out the invocation of the Tomcat-supplied "JspC" Ant task (and the corresponding set-up of its classpath), and replacing it with an Ant "exec" of the Glassfish "jspc" script with equivalent command-line arguments.

However, the Glassfish documentation for this seems a bit on the weak side. At least, I didn't find it particularly easy to locate any definitive documentation on the command-line options for the Glassfish V2 "jspc" script. Maybe I just didn't look in the right places. The program itself supports a "-help" option that lists its command-line options, but without much explanation. There's a more detailed explanation of the options in the Sun Application Server 9.1 Update 2 reference manual at http://docs.sun.com/app/docs/doc/820-4046/jspc-1m, but this doesn't entirely match the current Glassfish release (e.g. it doesn't include the recently-added "ignoreJspFragmentErrors" option). Nevertheless, it's the best documentation I've found so far. In any case, the options haven't yet diverged much from those of Tomcat JspC, so much of the Tomcat documentation remains relevant.

I'm also a bit unsure of the exact relationship between the Tomcat and Glassfish code. They both appear to be "Apache Jasper 2", but this doesn't seem to exist as a product in its own right, only as a component within Tomcat. The Glassfish code is presumably a copy or fork of the Tomcat code, but with its own bug-fixes and new features, and maintained and developed as part of Glassfish. With Glassfish being the reference implementation for new JSP versions, I assume the Glassfish implementation is now the main branch going forward, even if some of the changes get incorporated into both.

To add to my uncertainty, I'm also rather confused as to whether Glassfish does or doesn't also provide an Ant task for invoking its JSP compiler. There is an "asant" script that invokes Glassfish's internal copy of Ant with a suitable classpath, with various targets and supporting Ant tasks. There's also documention for previous releases of the "Sun Application Server" that show a "sun-appserv-jspc" Ant task. But the current Glassfish V2 documention doesn't seem to list any such task amongst its "asant" targets, nor otherwise document a "jspc" or "sun-appserv-jspc" Ant task. Maybe I just didn't find the right document. I guess I should just hunt around the Glassfish libraries for the relevant class, or try invoking it based on the previous release's documentation. But for the moment, invoking the "jspc" script is perfectly adequate for my purposes, so I'm sticking with that unless and until I get a chance to look at this again.

A few other findings:

• When given a complete web-application, the Tomcat 5 JspC compiler seems to process precisely those files that have a ".jsp" or ".jspx" extension. Maybe someone can enlighten me, but I can't see anything in the Ant task's attributes that allow it to be configured to process other file extensions. In contrast, Glassfish's jspc script seems to automatically process all file types that are identified by the web.xml as being JSPs.
• With the Tomcat JspC task, the JSP translation had to be followed by a separate run of "javac" to compile the resulting java source code. In contrast, the Glassfish jspc script supports a "-compile" option that carries out the compilation as part of its own processing. What's more, I gather this uses the JSR 199 Java Compiler API for "in process" compilation if this is available (i.e. when running on JDK 6 or higher), and seems much faster as a result.
• A slight limitation of the Glassfish jspc "-compile" option is that there doesn't seem to be any control over where the resulting class files are written. Instead, they just get written into the same directory as the java source files. For my purposes this doesn't matter, but if you wanted to put the class files into a specific location, or deploy them without the source code, you'd have to follow the jspc run with your own moving/copying/filtering of files as necessary.
• I'm not particularly concerned with the exact performance of this, but subjectively the builds do seem noticeably faster since switching over to the Glassfish JspC and using its "built-in" compile instead of a separate "javac" run.
• The Glassfish jspc script also supports a "-validate" option, which validates ".tld" and "web.xml" files against their schemas and DTDs. However, I don't currently use this, and instead use a separate run of Glassfish's verifier script to verify the finished web-application archive as whole.

I wonder if anyone can clarify the exact relationship between the Tomcat and Glassfish JspC implementations and the underlying "Jasper 2"? Or the exact status (and maybe classname, location, documentation etc) of any Glassfish "jspc" Ant task?

I actually can never write formal outlines except for papers.  Never was able, I should say.

--Glenn

P.S.  Sorry, it is freeware and this is the link for downloading KeyNote 1.0.

I was more than happy to see the large amount of new features and improvements, among them speed optimizations and the inclusion of a JavaScript editor with all the whistles and bells attached :D (but Aptana Studio Community Edititon still rules the scene in this respect IMHO). My joy was rapidly chilled when I discovered with some surprise (very unpleasant too) that there isn't a PDT release for Ganymede and the next scheduled release, that hopefully will work out of the box with Ganymede, for PDT is set for September only. I tried to use the update site from Ganymede's Update Manager with no success (I know this is n00bie behavior :( but hope is the last thing abandoned by anyone). After some extensive search using Google Search (Thanks Google) I stumbled across a blog article entitled "Eclipse  Ganymede / PHP / SVN" written by Haydn William in which he blogs, like myself, about the new Eclipse release and also tells about a posting on the  PDT wiki that helps to solve this issue. After reading it I was eager to try it out and !!! miracle !!! it worked without any additional problems, so now I'm the happy user of the new Eclipse Ganymede and PDT. Thank you William for the post and the PDT guys for providing this very useful development tool :) . I hope that this post will be of use to others as William's blog article was for me.

P.S. I forgot to mention that there are already integration builds of the next PDT release. I recommend using those instead on the nightly build mentioned on the wiki.

Screenshots:

[gallery]

]]> http://googlegazer.wordpress.com/?p=41 Thu, 26 Jun 2008 05:28:41 +0000 dsarna http://googlegazer.wordpress.com/?p=41 The revolution. It is a-coming.

The "Google Watch" blog discusses how Saleforce.com is taking advantage of Google's architecture so current Salesforce.com customers have been able for some time to directly work with Gmail, Google Talk, Google Calendar and the Google Docs spreadsheet, presentations and word processing applications from within the Salesforce.com platform.

Yesterday, June 23, the companies extended that collaboration theme to Salesforce.com developers with a tie between Force.com Toolkit for Google Data APIs, which lets programmers leverage the Google Data APIs within their applications and projects on Force.com.

Now Force.com programmers can directly call the Google Data APIs to plug any of the Google Apps functionality directly into the Force.com applications and share data and content between Salesforce.com's and Google's cloud computing platforms, and they can exchange data.

Clint Boulton quoted Ariel Kelman of SalesForce.com as providing the following example:

Let's say a salesperson wants to share a candidate list with an outside recruiter but not give the recruiter full access to the application. The salesperson can e-mail the recruiter a Google spreadsheet from Google Docs.

As the salesperson makes changes in Force.com through the Google Data APIs, it will update the candidate list on the spreadsheet. So, the recruiter can see those changes and interact with those changes.

"We can read and write information between our database and Google Docs," Kelman confirmed, and continued:

What we're trying to do is make it easier for developers to build applications that run in the cloud and as all of these cloud computing platforms proliferate, the more that vendors can do to allow developers to have access to the different computing platforms, the easier it becomes.

In effect, it's no different than what Microsoft did when it partnered with SAP and Business Objects in business intelligence ... back in the day to bolster its on-premises software functionality."

Boulton correctly observed that partnering is something that Microsoft has been doing for years. Small and large companies partner with Microsoft to benefit from Microsoft's cachet, imprimatur, and the free advertising, while Microsoft benefits by having its products become part of the heart and soul of thousands of applications, most of them business-oriented.

As the GoogleGazer reported earlier, Google is enticing developers to use its tools, its cloud-hosting, and its APIs and make them their own for development of Software As A Service ( SAAS) applications, which is where Google believes that the future lies. Google is making an astonishingly large amount of code available as Open Source having released over a million lines of code in that form already. Just look at their Open Source website.

(Though very late to the game, Microsoft has also (somewhat reluctantly) embraced Open Source of late. See this example, Microsoft's Open Source website and CodePlex, Microsoft's hosting site for Open Source.)

Those of us barely able to remember when once we had hair can hark back to the late '80s and early '90s. Microsoft was then desperately trying to see its tools adopted by the development communities, and especially the corporate developers, who were then using SyBase, PowerBuilder and other mostly forgotten tool. They regarded Microsoft as a purveyor of "toy" development tools for sissies. To change that perception, Microsoft hired a staff of evangelists, and spared no expense to pamper and woo developers of all stripes, cleverly realizing that by controlling developers they would control the desktop and continue their hegemony. It took a few years, but the effort was largely successful, especially for corporate development The effort survives, in much more modest form, as Microsoft Developer Network, as the battle seemed substantially won.

No so fast.

Google is now battling Microsoft on many fronts, and developers are becoming a prime battleground. Like the Microsoft of old, Google is pampering developers at conferences, and with tee shirts and food. However, its commitment to Open Source and non-proprietary open industry standards are perhaps its most potent weapons. For years, enterprises have chaffed at the heavy "taxes" they need to pay Microsoft for each desktop, primarily in the form of licenses for Windows, Office, and Exchange, but also in supporting armies of technicians that need to constantly upgrade those desktops to work with the latest release of this or that Microsoft upgrade.

There is a rebellion underfoot, and Microsoft's heavy-handed attempts to "force" the adoption of Vista have only fanned the flames of rebellion.

Technology is also on Google's side. Improved and more universal Internet and really powerful cloud computing has clearly brought us back to the so-called "thin client" era, where most of the really good stuff happens on the server side. Mozilla's Open Source FireFox 3.0 is also playing an important role. The upcoming near universal availability of the Internet browser on all cell phones, PDAs, and other devices and - finally - the move to high speed 3G and 4G cellphone technology are changing the paradigm once again.

Open Source, Cloud Computing, and Software as a Service (SAAS) are the future. Complex, proprietary, failure-prone desktops, with their heavy taxation burden to Microsoft represent the past.  A major paradigm shift is underway, and there will be winners and losers. Menlo Park's Sand Hill Road venture capitalists are rubbing their hands in glee. Paradigm shifts create huge opportunities for start-ups to become billion dollar companies in a short time.

As James Otis famously said in the years just prior to the American Revolutionary War, "Taxation without representation is tyranny." And it's rebellion against tyranny that fuels revolution. That's been the American way now for well over 300 years.

Guess I wasn't looking well enough, because today I (finally) stumbled upon a solution which meets all of my needs and more, Assembla.

If you're looking for a place to host your development projects, I'd highly suggest Assembla, even if only for the *free* hosted Subversion repository which can be made private or public, unlike other free services which only offer public open-source hosting. Not that I'm knocking Sourceforge or Google Code, it's just that I'm working on a consulting project that can't be left out in the open (as I'm sure is the case with many of you out there as well).

Here's a list of their plans (current as of this posting):

...and since you probably can't read that without clicking on the expanded image, here's the link to their pricing plans: http://www.assembla.com/tour

The array of development tools they have to offer is quite impressive, and I'm seriously considering upgrading to the Commercial plan ($12.50/month) to get more space.

For what it's worth, Box.net, if you're listening - you should really consider offering (real) WebDAV support and/or Subversion through your API, because *that* would make your site the killer app I've been waiting/paying for.

Also, here's another great post with information about Assembla:
http://coding-time.blogspot.com/2008/04/free-subversion-wiki-at-assemblacom.html

...and they also have a great post about Subversion and how it works:
http://coding-time.blogspot.com/2008/04/subversion-visually-explained-in-30sec.html

Some of the responses questioned whether there will be a Cocoa for Windows.

While Roughly Drafted's article is a good overview of what happened with Mac OSX and its API, it missed some important information about NeXT.

Back in the days of NeXT, when Steve Jobs failed to push the hardware in the market, NeXT developed a different flavor of NeXTSTEP OS, called OpenStep. It runs on top of Windows and Sun. Essentially, it was a framework on top of the native API of each OS.

Cocoa is really based on OpenStep instead of NeXTSTEP. That's why we have two layers - the Carbon, and Cocoa on top.

So, the question on whether Cocoa CAN be ported to Windows is a definite YES. It was done 15 years ago. It can still be done now.

However, it is very unlikely to make Cocoa to work with .NET. First, they use two totally different languages. Cocoa uses Objective C. .NET uses C#. That makes it very difficult to use one framework in another one.

When API is standard C procedure calls, vendors and developers can use any language and create a variety of tools and framworks. With System 7, we had MacApp, THINK, and PowerPlant, three major C++ frameworks. We had a couple of Basic compilers, whose name I cannot recall at this moment.  Apple also briefly tried a language called Dylan (short for Dynamic Language). Metrowerks also had a super fast Pascal compiler, which works with PowerPlant.

Today, most of those tools and frameworks are retired. There is still Qt, a cross-platform C++ framework. It is built on top of Carbon, and missing a lot of platform specific features.

As Apple pushes toward Cocoa, and Microsoft pushes toward .NET, it has been very difficult for development tools companies. The classic example on Mac is Metrowerks. The classic example on Windows is Borland(Codegear). Both of them have to change their business model and abandom the mainstream tools market. Both of them had great tools on top of the native C API of each OS, but unable to move forward when the OS become object-oriented.

I have mixed feelings about Cocoa and .NET. They are great frameworks. However, it is almost impossible to write cross-platform code with them. Yes, you can write Objective-C and make it fairly cross-platform on Mac OSX and iPhone, and you can write C# and make it fairly cross-platform on Windows and Windows Mobile. However, there is a big gap between Mac OSX and Windows.

Cocoa can be built on top of WinAPI, but cannot be built on top of .NET. That limits the potential use of Cocoa on Windows.

And why would Apple do that anyway? No cross-platform tool ever succeeded in large scale. Even Apple's own effort failed - in 1995 (around that time), Apple partnered with Symantec (the owner of THINK C at that time) to develop a cross-platform framework called Bedrock.

So, I doubt we will see Cocoa for other platforms except in Apple's labs.

We're ready for a few more people to start trying it out, so if you're interested just let me know - either via this blog's "contact me" page or via my company e-mail address of mike-at-openbrace-dot-com.

In outline, ObMimic provides a comprehensive set of fully-configurable test doubles for the Servlet API, so that you can use normal "plain java" tools and techniques to test servlets, filters, listeners and any other code that depends on the Servlet API. We call these test doubles "mimics", because they "mimic" the behaviour of the real object.

We see this as the ultimate set of "test doubles" for this specific API: a set of plain Java objects that completely and accurately mimic the behaviour of the "real" Servlet API objects, whilst being fully configurable and inspectable and with additional instrumentation to support both "state-based" and "interaction-based" testing.

If you find servlet code harder to test than plain Java, ObMimic might be just what you're looking for.

With ObMimic, you can create instances of any Servlet API interface or abstract class using plain no-argument constructors; configure and inspect all relevant details of their internal state as necessary; and pass them into your code wherever Servlet API objects are needed. This makes it easy to do detailed testing of servlets, filters, listeners and other code that depends on the Servlet API, without needing a servlet container and without any of the complexities and overheads of packaging, deployment, restarts/reloads, networking etc.

ObMimic includes facilities for:

• Setting values that are "read-only" in the Servlet API (including full programmatic control over "deployment descriptor" values and other values that are normally fixed during packaging/deployment, or that have fixed values in each servlet container).
• Examining values that are normally "write-only" in the Servlet API (such as a response's body content).
• Optionally recording and retrieving details of the Servlet API calls made to each object (with ability to turn this on and off on individual objects).
• Controlling which version of the Servlet API is simulated, with versions 2.3, 2.4 and 2.5 currently supported (for example, you can programmatically repeat a test using different Servlet API versions).
• Detecting and reporting any calls to Servlet API methods whose handling isn't strictly defined by the API (e.g. passing null arguments to Servlet API methods whose Javadoc doesn't specify whether nulls are permitted or how they are handled).
• Controlling the simulation of container-specific behaviour (i.e. where the Servlet API allows variations or leaves this open).
• Explicitly forcing Servlet API methods to throw a checked exception (e.g. so that you can test any code that handles such exceptions).
• Handling JNDI look-ups using a built-in, in-memory JNDI simulation.

There are no dependencies on any particular testing framework or third-party libraries (other than Java SE 5 or higher and the Servlet API itself), so you can freely use ObMimic with JUnit, TestNG or any other testing framework or tool.

In contrast to traditional "mock" or "stub" objects, ObMimic provides complete, ready-made implementations of the Servlet API interfaces and abstract classes as defined by their Javadoc. As a result, your tests don't have to depend on your own assumptions about the Servlet API's behaviour, and both state-based and interaction-based tests can be supported. ObMimic can even handle complex sequences of Servlet API calls, such as for session-handling, request dispatching, incorporation of "POST" body content into request parameters, notification to listeners, and other such complex interactions between Servlet API objects. It can thus be used not only for testing individual components in isolation, but also for testing more complete paths through your code and third-party libraries.

With the appropriate configuration, it's even possible to test code that uses other frameworks on top of the Servlet API. For example, we've been able to use ObMimic to test "Struts 1" code, and to run ZeroTurnaround's JspWeaver on top of ObMimic to provide out-of-container testing of JSPs (as documented previously).

As a somewhat arbitrary example, the following code illustrates a very simple use of ObMimic to test a servlet (just to show the basics of how Servlet API objects can be created, configured and used):

import com.openbrace.obmimic.mimic.servlet.http.HttpServletRequestMimic;
import com.openbrace.obmimic.mimic.servlet.http.HttpServletResponseMimic;
import com.openbrace.obmimic.mimic.servlet.ServletConfigMimic;
import javax.servlet.Servlet;
import javax.servlet.ServletException;
import java.io.IOException;

...

/* Create a request and configure it as needed by the test. */
HttpServletRequestMimic request = new HttpServletRequestMimic();
request.getMimicState().getRequestParameters().set("name", "foo");
request.getMimicState().getAttributes().set("bar", 123);
... further request set-up as desired ...

/* Create a response. */
HttpServletResponseMimic response = new HttpServletResponseMimic();

/*
 * Create and initialize the servlet to be tested (assumed to be a
 * class called "MyHttpServlet"), using a dummy/minimal
 * ServletConfig.
 */
Servlet myServlet = new MyHttpServlet();
try {
    myServlet.init(new ServletConfigMimic());
} catch (ServletException e) {
    ... report that test failed with unexpected ServletException ...
}

/* Invoke the servlet to process the request and response. */
try {
    myServlet.service(request, response);
} catch (ServletException e) {
    ... report that test failed with unexpected ServletException ...
} catch (IOException e) {
    ... report that test failed with unexpected IOException ...
}

/*
 * Retrieve the response's resulting status code and body content,
 * as examples of how the resulting state of the relevant mimic
 * instances can be examined.
 */
int statusCode
    = response.getMimicState().getEffectiveHttpStatusCode();
String bodyContent
    = response.getMimicState().getBodyContentAsString();
... then check them as appropriate for the test ...

For further examples and details, refer to the previous posts "First experiments with out-of-container testing of Servlet code using ObMimic" part 1 and part 2, "Out-of-container JSP testing with ObMimic and JspWeaver", and the related post "Mocking an API should be somebody else's problem".

There are also more extensive examples in ObMimic's documentation.

ObMimic isn't open-source, but it will have a zero-cost version (full API coverage but a few overall features disabled, such as the ability to configure the Servlet API version, control over how incorrect/ambiguous API calls are handled, and recording of API calls). There will also be a low-cost per-user "Professional" version with full functionality, and an "Enterprise" version that includes all of ObMimic's source-code and internal tests (with an Ant build script) as well as a licence for up to 200 users.

At the moment there's no web-site, discussion forums or bug-reporting mechanisms (all still being prepared), but ObMimic already comes with full documentation including both short and detailed "getting started" guides, "how to"s with example code, and extensive Javadoc - and for this private beta I'm providing direct support by e-mail.

Anyway, if you'd like to try out ObMimic, or have any questions or comments, or would like to be informed when there's a more public release, just let me know via the "contact me" page or by e-mail.

"The highly acclaimed introduction to Cocoa-recommended most by experienced Mac OS X developers now updated and expanded. Here's what critics said about the first edition: "Reading this book is the absolute best way to learn how to harness the power of this amazing technology."
-Andrew Stone, President, Stone Design, www.stone.com "Make sure this is the first one you pick up. It's the best book for a beginning Cocoa programmer."
-From the review on HyperJeff.net& "I love this book. The descriptions are clear, the examples logical. Everything a programmer needs to get up to speed on Cocoa."
-Dave Mark, Editor, MacTech Magazine
To help programmers develop applications for Mac OS X, Apple is now giving away XCode, Interface Builder, and the Cocoa frameworks-the tools used to create Safari, GarageBand, Mail, and the iApps. Cocoa- Programming for Mac- OS X, Second Edition, will give you a complete understanding of how to use these tremendously powerful tools and frameworks to write full-featured applications for the Mac.

Guiding programmers through the key features of Cocoa, this book emphasizes design patterns that enable you to predict the behavior of classes you have never used before. Written in a tutorial format, it takes you step-by-step through the creation of six applications and an Interface Builder palette. Each project introduces several new ideas, and as each concept or technique is discussed, the author, drawing on his own extensive experience, shows you the right way to use it.

Updated for Xcode and Mac OS X 10.3, new chapters in this second edition include coverage of OpenGL, AppleScriptability, the undo manager, creating frameworks, and a brief introduction to using GNUstep on Linux.

"

There's a reason that a large slice of the open-source movement has defected from running Linux on its laptops to running Mac OS X. The reason is the Unix core that underlies Mac OS X, and the development tools that run on that core. Cocoa makes it easy to create very slick Mac OS X interfaces for software (as well as to create applications in a hurry), and this new edition of Cocoa Programming for Mac OS X does an excellent job of teaching its readers how to put a Cocoa face on top of code (Objective-C code almost exclusively). If you know something about C and/or C++ programming and want to apply your skills to the Mac, this is precisely the book you want.
Author Aaron Hillegass teaches a Cocoa class, and his book reads like a demonstration-driven lecture in a computer lab. That is, the book takes a heavily example-centric approach to its subject, beginning with simple announcement windows and proceeding to cover the more advanced controls and object-oriented features of Cocoa and Objective-C. Throughout, he hops back and forth between descriptions of the goal to be accomplished, listings of the code that does the job, and instructions on how to use the Mac OS X development tools to speed the development process. --David Wall
Topics covered: How to write software for Mac OS X in Objective-C and, especially, with Cocoa. The new edition shows how to use NSUndoManager, add AppleScript capability to an application, do graphics work with OpenGL, and use Cocoa under Linux using GNUstep. As well, all the basic controls and design patterns are covered.

Order Cocoa Programming for Mac OS X from Amazon for $28.34

Don't have Amazon Kindle? You can always purchase it from here
Or if you prefer to read the Print editions instead, you can get it from here

Other Kindle Books of Interest
Mac OS X Internals: A Systems Approach
Beginning Mac OS X Programming
Programming with Quartz: 2D and PDF Graphics in Mac OS X
Rubyisms in Rails, Digital Shortcut
undefined

For the last couple of months I have been using Eclipse more and more in both a personal and a professional setting. Eclipse can be an overwhelming and daunting IDE but is a very powerful one too. One of the features I hadn't discovered until recently is the breakpoints properties screen. This screen has a number of cool features but I'd like to highlight two of them in this blog post.

Hit count

Eclipse allows you too only suspend the thread for debugging when hitting the breakpoint a certain number of times. Look at the example code below.

[sourcecode='java']
for (int i = 0; i <= args.length; i++) {
System.out.println(args[i]);
}
[/sourcecode]Imagine a much more complex version of the scenario seen above. You're skipping through arrays and suddenly an ArrayIndexOutOfBoundsException is fired. Wouldn't it be easy to be able to debug this piece of code without having to click through the loop a gazillion times until you reach the phase of the loop you're interested in?

Eclipse makes this all possible in its breakpoints properties screen. This screen is shown below and can be opened by right clicking a breakpoint and selecting properties in the menu. As you can see in the image below you enter a numerical value which indicated how many hits a breakpoint should get before suspending the thread and allowing you to dive into the code.

Conditional breakpoints

An even more powerful feature than the one shown above is the conditional breakpoint. An example of this can be seen in the picture below.

Using the settings seen in the image the breakpoint only suspends the thread when the condition in the text box is true. You can enter any boolean condition in this box.

Both of the above features allow for some very, very powerful debugging.

Here is a quick comparision between the two that I found over the internet.  Do note that this was posted a few years back.  Those with experiences with SVN/CVS, do comment on the accuracy of the comparision.

http://www.pushok.com/soft_svn_vscvs.php

"An effective web design is one in which your users are able to find information quickly and in a logical fashion."

We all visit websites, leaving many of them quickly for any of the following reasons:

• Loads too slowly
• Too hard to navigate around
• Information you're searching for seems like a game of hide 'n seek

If you’re interested in analyzing and optimizing your page layout Six Revisions has posted some extremely useful tools that you can use to help.

A couple of tools listed on that site include -

ClickHeat, which is an open source visual tool for showing "hot" and "cold" zones of a web page. It allows you to see which spots users click on most, and which spots are being ignored

Crazy Egg, who offers a myriad of analytical tools to help you visualize what visitors are doing.

Check out the rest of that list and see if your site can benefit from any of those tools.