Perforce integration

[anonymous]

Trac looks perfect to me - except I'm stuck with Perforce and I can't use Subversion. I'd love to see Trac integrate with p4.

[anonymous]

Perforce does rule, but adding support for a non-open source SCM may not be the direction they are interested in.

[Scott]

I'd really like to see Perforce integration too!

[anonymous]

Of course, Perforce is free for open-source projects, so how bad is it really? ;)

[anonymous]

Just another vote for Perforce support.

[mgood]

Under the  Perforce API tools there is a Python binding listed. However, the licensing terms seem to be incompatible with the GPL license that Trac uses:

# License:
# This file and any derivatives or translations of it may be freely
# copied and redistributed so long as:
#	1) This license and copyright notice are not changed.
#	2) Any fixes or enhancements are reported back to either the
#	   author (mwm@phone.net).
# and any of:
#	a) The source is redistributed with it.
#	b) The source is compiled unmodified, and instructions for finding
#	   the original source are included.
#	c) The source is made available by some other means.

In particular, the clause that requires notifying the author of changes goes against  this entry on the GPL FAQ.

I didn't find the licensing terms of the Perforce C/C++ APIs, so I'm unsure whether there would be any barriers towards writing another Python binding for them.

Besides that I think we need someone familiar with Perforce to help with the development effort, since I don't know of any current Trac developers that use Perforce.

[anonymous]

The way I read it, that FAQ entry says you can't require people to notify you when they receive the software. It doesn't say anything about notifying the author of modifications.

[dobesv@…]

Is this topic dead? Is there any hope whatsoever for this idea?

[anonymous]

I would very much like this too. It's possible I could play around with it at some point, but I promise nothing. :-)

I don't personally use Perforce, but I have used it at a couple of places I've worked. It's versioning model is similar enough to Subversion's that I can easily see Trac supporting it.

[eric-trac@…]

I would very much like this too. It's possible I could play around with it at some point, but I promise nothing. :-)

I don't personally use Perforce, but I have used it at a couple of places I've worked. It's versioning model is similar enough to Subversion's that I can easily see Trac supporting it.

[eric-trac@…]

One company that uses Perforce that might end up using Trac if it supported Perforce is Amazon.

[jparks@…]

I've created a plugin for Perforce. It can be download from  http://www.jparks.net/download/perforce-trac.zip

[thomas.tressieres@…]

I was also very impressed by Trac and the subversion integration. Two months ago i was doing some tests with Subversion, Perforce and StarTeam.
But, my team members choosed Perforce as a replacement for PVCS and VSS. So i was looking for a new tracker software...

Thanks to Jason Parks, based on his developments, i made some improvements in perforce.py (file in attachment). It's my first python program, so there are certainly errors and improvements :-(

If you have any suggestions or ideas or bugs fixes, please send them.

[thomas.tressieres@…]

second version (based on Jason Parks work)

[cboos]

Well, there's currently much work done on the versioncontrol backend side (see log:sandbox/vc-refactoring).

In particular, it should be possible to create a plugin for Perforce, following the example set by source:sandbox/mercurial-plugin.

[anonymous]

I put my first plug-in using the framework made by cboos in the Track Hacks site. The first version is available  here. As soon as i have the write access to the Track hack repository i will chek-in my sources.

[kristjan@…]

Browsing perforce directories was incredibly slow and tended not to work using mod_python. It turned out that to get the latest changeset of a directory, all the files were being examined. The fix is simple. Replace

for dir in dirs: 
    myDir = dir['dir'] + "..." 
    logs = self.p4c.run("fstat", myDir) 
    revs = [] 
    for myLog in logs: 
        newRev = int(myLog['headChange']) 
        if not newRev in revs: 
        revs.append(newRev) 
    revs.sort()
    yield PerforceNode(dir['dir'], str(revs[-1]), self.p4c, self.log, Node.DIRECTORY)

at perforce.py:301 with

for dir in dirs:
    changes = self.p4c.run("changes", "-m 1 -status submitted", dir["dir"]+"...")
    maxrev = str(changes[0]["change"])

yield PerforceNode(dir['dir'], maxrev, self.p4c, self.log, Node.DIRECTORY)

Also, I noticed that when changelists in Perforce were updated, the changes were not reflected in trac. I traced the problem to the following line in (changeset.py:75)

req.check_modified(chgset.date, diff_options[0] + ''.join(diff_options[1]))

Simply comment this out to get changesets to update.

[kenjin@…]

Make p4 class attributes to address p4d process spawning.

[kenjin@…]

I used the second version (created by thomas.tressieres@…) and noticed that p4d process is spawned whenever item in repository is browsed and it resulted in hundreds of p4d processes were running. I believe the source of the problem is an connection of P4 is established in __init__ of PerforceRepository, and it's never closed.

The possible solutions are either

1. Close p4 connection when PerforceRepository is no longer used.
2. Make p4 object class attribute and share one connection across instances of PerforceRepository.

The second approach is easier so I created a patch. I'm not familiar with python and P4Python so that I'm not sure what's happen on concurrent accesses, but I could work around the process spawning, which made the entire perforce operation slow down very much.

[thomas.tressieres@…]

I will port the modification sent by kristjan@… in the  source repository.

Kenjin, which platform do you use ??
I didn't noticed the swawning of perforce server on Windows. But maybe this event occurs on other platforms...
If you can send me some feedback, i will integrate your modification also on the  http://trac-hacks.swapoff.org/wiki/PerforcePlugin

[Kenji Nakamura <kenjin@…>]

Thomas, p4d is running on Fedora core 3, and trac is on python2.4, 2005.1 p4api, and Mac OS X 10.4.3. I'm bit surprised to hear it doesn't have problem on Windows, since I cannot find the code to call p4c.disconnect(). Can you check the established connections with command such as netstat? I saw many connections were established to p4server's port(1666) from the server on which trac was running.

Thanks,

Kenji

[anonymous]

Kenji, you're right there are some problems on Windows: one thread was created each time a refresh was done. I merged your patch with the p4trac code  here

Thanks,

Thomas

[anonymous]

There is a new Python interface for Perforce called  PyPerforce that could also be used to write a Perforce plugin for Trac.

It supports multi-threaded apps and so should see improvements in handling multiple concurrent requests for ModPython on Windows.

It also supports streaming of command output which may make it possible to write an implementation that scales better when processing large repository files. However, I'm not familiar enough with the internals of Trac to know if this is the only bottleneck.

[lewisbaker@…]

I've been working on a new version of the Perforce plugin for Trac that uses  PyPerforce.

It supports TracTimeline display of changesets and has a few other improvements over the existing plugin by thomas.tressieres@…. However, it's not as feature complete as I'd like it to be so any assistance in improving it would be great (see the README for a list of features that still need implementing).

You can download it from  here and find more details in the  release notes.

[mgood]

Thanks to the people working on the plugin for this. Since it seems that there is a working implementation Perforce users should now use this plugin.