Joseph - 07/Feb/08 11:18 PM Any progress on this?

Daniel Ostermeier - 08/Feb/08 05:03 AM Hi Joseph. No progress at this stage. The crux of the problem is having enough information available locally to form the fisheye URL. We will need to review the latest fisheye release and see if it is still a problem for us.

Joseph - 08/Feb/08 05:08 PM As of Fisheye 1.4.1, it still is.

jason - 08/Feb/08 06:14 PM Hi Joseph, Thanks for this update. As Daniel mentioned, there is an issue here with not necessarily having all the information we need to form the path. In Pulse we get the file names in depot format, and to convert them into client format we need to take the client mapping into account. I am unsure of how to do this for non-trivial mappings without a round trip to the Perforce server for every file in the changelist, which is way over the top. Alternatives could be: 1) To investigate if it is possible to pass a depot path to Fisheye in some way. This would be great but may not be possible. 2) Change the way those links work so that we can take the round trip to Perforce hit only when you click on the link. This still affects usability so I am not too keen. 3) Do the path mapping in Pulse by implementing compatible Perforce client mapping. Client mapping in general is quite powerful so getting this compatible could be difficult. One advantage is we could do this over time and the first 10% of the implementation would probably work for most cases. The downside is any incompatbility would mean the solution is incomplete. I need to look into 1) first. If this is not possible, then 3) may be the best option. The complication of reimplementing the mapping to be 100% compatible is what has held this back.

Joseph - 08/Feb/08 06:31 PM Option 4) remove the link.

jason - 11/Feb/08 02:05 PM Hi Joseph, I take your point that if we can't get it to work then we should remove the links. If I can't solve it by 1) or 3) then this is what we will need to do, and will need to document that our Fisheye support does not extend to Perforce as yet.

Joseph - 12/Feb/08 10:30 PM If I understand the problem, you're looking for a mapping of the Fisheye repository name to the Fisheye location name. One fix is to check out the new remote API available under the "/admin-api/" address. When you open this page in a browser you'll be asked for password - leave username field empty and the password is your admin password for FishEye. It's a REST remote API. By default when you open this page you'll get some documentation describing the remote API. To set up the mapping, I used "/admin-api/config", if you try to open this page you'll get a XML file with your repository configuration. You'll have to parse it to get information about perforce repository location. If you find this helpful, I take a large t-shirt. If not, then I guess I owe you one.

jason - 13/Feb/08 06:04 PM Hi Joseph, Thanks for the info - I had not seen the Fisheye API before. This is an interesting point indeed as it led me to discover that Fisheye only appears to support a limited view of a Perforce server. It seems that you can only specify a single path under which Fisheye will scan, rather than specifying a normal Perforce client mapping. Hence I think a lot of the complication I had expected does not actually apply, which may make this problem quite easy to fix. Now, a t-shirt is a possibility, but at the moment we have no more stock out of our first limited run. We will need to put you on the short list for the next batch ;).

jason - 14/Feb/08 07:37 PM OK, thanks to your input Joseph I have a decent fix for this for 1.2, and all my worries were over the top. Once I got a Fisheye/Perforce test setup going it was easy enough to fix to a reasonable degree. The fix put in place will not easily adapt to all uses, but I suspect it will cover a large part. The fix can handle these cases: 1) The most basic case, where you configure your Perforce paths in Fisheye as "//<depot name>" for all of your Perforce projects. In this case the integration Just Works now. 2) The case where you have one Fisheye Perforce path of any length for all of the projects you care about. In this case you need to set the system property pulse.fisheye.strip.prefix to this path so that it will be stripped out when constructing URLs. The third case is where you configure Fisheye with non-trivial Perforce paths that are different for multiple projects. Since the system property used to solve case 2) above is Pulse-server-wide, this situation cannot currently be handled. It cannot be fixed without a schema change, so will need to wait for 2.0 (see CIB-1375). Refer to change 4092.