Hi Karen,
I pretty much agree with Cedric's comments. Let me chip in a bit more info to help you in your design process.
First, it's useful to know that Hackystat is not designed to be a real-time collaborative system, in the sense that behaviors it senses from one developer could be communicated to another developer within a short (i.e. seconds to minutes) period of time. That would be a useful software engineering tool, but it's not what Hackystat is designed to accomplish.
From a communication/coordination point of view, Hackystat is designed tooperate most effectively at the grain size of days: the activities picked up by sensors from the development group during a day are analyzed and the results made available to the team on the next day. (There can be exceptions to this, but this is the general spirit of the architecture).
Another result of not needing to satisfy real-time communication requirements is that we have designed all our sensors to buffer the accumulated data locally for a (user configurable) number of minutes, which defaults to 10. Furthermore, if the user is not connected to the net, the data is cached locally until a later session when the user is reconnected. (This enables people to take their laptop on trips, hack while offline, and get their accumulated sensor data sent back to the server once they get back to work.)
All of this creates obstacles to your goal of using Hackystat to create a 'near-real time' CVS sensor plugin to Eclipse. If this is an important design goal for you, then you might want to check out Palantir <http://www.ics.uci.edu/~asarma/Palantir/>, which is specifically designed to provide real-time CM awareness.
If real-time awareness is not an important design goal, then the next question is: what would be the value-added of having a client-side (i.e. Eclipse) CVS sensor over our current approach? When we were initially designing our CVS sensor, we decided upon a server-side orientation because it allowed us to collect the data independently of the specific CVS client software, and thus avoided the need on our side to develop individual sensors for all of the different implementations of CVS clients. So far, we have not encountered an analysis situation where knowing more about the client side CVS state would actually add value to an analysis. (Note that if you use our CVS sensor in conjunction with our regular Hackystat plugin for Eclipse, then we can do data synthesis on the server side to determine, for example, what file(s) you were editing around the time of any given commit, or what unit tests were being run, etc.)
It might be useful to understand more about what specific software engineering questions you're trying to answer using CVS data. From that, we would be able to understand better whether Hackystat and the current CVS sensor design would be suited or not to your needs. If it's simply the need to represent CVS branches, then we could and should extend the server-side sensor to accomodate this need.
Cheers, Philip
--On Friday, October 8, 2004 1:53 PM -1000 "(Cedric) Qin ZHANG" <[EMAIL PROTECTED]> wrote:
Hi, Karen,
I am sure it's possible to write an eclipse sensor that detects eclipse commit activity. But the current cvs sensor works fine for our group, and we don't have any plan to write an eclipse-side sensor in the near future. If you decide to implement it on your own, I am sure our in-house eclipse plug-in guru Takuya will be glad to provide assistance you need.
It should not be difficult to overcome the current restriction of only picking up commits on the main branch, since the underlying Apache JRCS library supports detection of commits on all branches. Our decision is made mainly because the major client of the sensor (i.e. our own research group) only uses cvs main branch. I am thinking about lifting the restriction in the future when I have more time. If you have an urgent need for this feature, please feel free to modify the existing code (our code is GPL, your change needs to be GPL as well), and I will be glad to provide technical assistance.
Current cvs sensor requires the task to be scheduled periodically (it does not have to be daily) to pick up commits information. This works fine with us since hackystat is not a hard real-time system, in the sense that being able to see your data for the current day won't help you too much in gaining insights of your development activity. But if you really want to pick up commits on cvs side as they occur, I remember I read somewhere that there is one file in CVSROOT you can modify so that a custom task can get called every time there is a commit operation. This is all the information I have. You need to get a really good CVS hacker's manual to find out what exact modification you need. If you can find that out, I think I can modify current sensor to send data in real time. (However, my concern is that since the sensor is a java program, it's relatively slow to run. It will be called each time a file is committed, and if a user is committing lots of files, then there would be a considerable delay in cvs server response.)
Hope this helps.
Cheers,
Cedric
[EMAIL PROTECTED] wrote:Hi Cedric,
I work in the Software Architecture and Processes Group of Corporate Research for ABB, and am also a PhD student working with Dr. Laurie Williams at NCSU. I am currently piloting Hackystat for ABB, primarily using Eclipse on a Windows 2000 PC. I have Hackystat working with the Eclipse and Junit sensors, as well as Office. I am currently doing my CVS work (commits, etc.) via the pre-installed Eclipse CVS plugin. I understand that the current CVS sensor is needed for people using CVS directly, but I am wondering if you think it would be feasible to write a Hackystat CVS sensor that would intercept the commits as they are done through the Eclipse CVS plugin? This would (I think) get around the current restriction of only picking up commits on the main branch, would avoid the need for scheduling a daily task to query the CVS repository and transmit data, and would minimize lag time, making the commit sensor data availability near real time. If it works, it should then be possible to extend this approach to instrumenting the Eclipse plugins for other CM systems, e.g. Clearcase.
I do not yet have experience writing either Eclipse plugins or Hackystat sensors, but would be willing to help with the work on developing such a sensor.
Mahalo, Karen :)
