[MonoDevelop] VersionControl Add-in for Perforce

[Casey Marshall]

On Tue, 2008-07-01 at 22:05 -0400, Michael Hutchinson wrote:
> On Tue, Jul 1, 2008 at 7:56 PM, Casey Marshall
> <cmarshall at pacificbiosciences.com> wrote:
> > Hi.
> >
> > I'm looking to implement a VersionControl Add-in for MonoDevelop that
> > uses Perforce as the back-end, and had a few questions about VC and
> > Add-in development:
> >
> >   - First, has someone already written such a thing? (I'm assuming not,
> > given Google's silence).
> 
> Nope. the only (successful/released) version control addin that I know
> of is the SVN one in trunk.
> 
> >   - It doesn't look like there's any way for MonoDevelop to figure out
> > that a particular solution/project/file/etc. is already under version
> > control -- I only see hooks to "checkout" and "publish" code. If this
> > doesn't exist, that would obviously be a neat feature.
> 
> It does do that. The real fun is all in the Repository instances that
> the VersionControlSystem returns, which has (among many other things)
> an IsVersioned (string localPath) method.
> 
> Take a look at http://anonsvn.mono-project.com/viewcvs/trunk/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl/MonoDevelop.VersionControl/Repository.cs?view=markup
> and the SVN implementation:
> http://anonsvn.mono-project.com/viewcvs/trunk/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion/MonoDevelop.VersionControl.Subversion/SubversionRepository.cs?view=markup
> 
> >   - Related to that, how does the VC add-in know that a solution is
> > under version control?
> 
> By asking the version control addins if the project file is under
> version control GetRepositoryReference in VersionControlService, and
> using the first one that returns a non-null Repository.
> 

Oh, sweet. Thanks for the tip.

> >   - I'd like to add a simple preference pane, which lets you globally
> > enable the Add-in. I presume this is easy to do, I just haven't looked
> > hard enough yet at how to do it.
> 
> Yes, that's pretty easy, but why can't it just be enabled with the
> addin manager?
> 

Yeah, point.

> >   - Does RequestWritePermission do what I hope it does? As in, if a file
> > needs to be written by MonoDevelop, will this be called if the file is
> > not writable? This is clearly desirable, here, since Perforce leaves
> > un-checked-out files read-only. I don't see any other command in
> > Repository that ties to a "check out this file for editing." (which, of
> > course, VC systems that are better than Perforce don't usually have, but
> > I'm working with what I'm stuck with)
> 
> That's a good question. The Repository does have Lock/Unlock methods,
> but I ahve no idea if they are actually used. I'm pretty sure that a
> lot of code in MD wouldn't respect this.
> 
> That said, any patches needed to make it work properly would be welcome :)
> 
> [I can't actually find RequestWritePermission]
> 

It's actually RequestFileWritePermission. Perforce has separate
lock/unlock commands, which I'd like to try to support, too.

This is probably most important for project files, which seem to get
written just by being used, and I think Visual Studio's Perforce
integration checks these out automatically. For checking out normal
files, just having an item in the contextual menu to check the file out
for edit would be OK.

Related to this, is there a mechanism for adding a verb to the version
control menu for "open for edit" commands?

(writing that last paragraph, it occurs to me that "no, except for
modifying MD and submitting a patch" might be the answer, which is
acceptable, too)

> >   - Is there a simple way to get a "console," or some way to print out
> > what p4 commands are being run? I think the IProgressMonitor plugs into
> > one, but I don't get passed one with every command -- I'm implementing
> > this by just using the `p4' command-line program, and I'd like to have
> > this for debugging and monitoring.
> 
> Well, there's MonoDevelop.LoggingService.LogDebug (which can be
> enabled using environemnt variables and directed to the console, a
> file, and/or the internal message pad)
> System.Diagnostics.Debug.WriteLine might be more approprate since
> references to it get ignored if you compile without /d:DEBUG.
> 

I'll look at LogDebug. The idea here is to emulate the "console" output
you get in the perforce GUI -- it actually writes a log of all its
commands as if they were being done on the command line, so I'd want
this enabled all the time, and having them appear in the message pad is
ideal.

> Also, if you can P/Invoke into some stable library, that'll be a *lot*
> faster than constantly forking command-line processes. Dunno if
> perforce supports this or not.
> 

I don't think there is any programmatic API, through I saw references to
COM bindings on Windows. And yes, I agree :-)

Thanks.