From chris at cjack.com  Fri Oct 28 14:19:10 2005
From: chris at cjack.com (Chris Thomas)
Date: Fri, 28 Oct 2005 10:19:10 -0400
Subject: [TxMt Plugins] Version Control Plugins
Message-ID: <79C3FD7C-A924-47FA-AA84-62F4B900CB0B@cjack.com>

Just some quick notes while I'm idly thinking about this.
...
For maximum flexibility, probably most version control operations  
should still be handled through the current bundle system. However,  
there are two very desirable things we can't do with the bundles:

(1) a context-sensitive version control menu (perhaps a "Version  
Control" submenu for the context menu)
(2) a graphical indication for each file of the current version  
control state - another icon in the newly mousable status bar :)

To implement those features, TM should be able to lazily:

(a) Discover which version control system is in use for a given  
filesystem node
(b) Given the version control system, use it to find the state of a  
given file or folder
(c) Given the version control system, discover which bundle commands  
should be appear in the version control submenu

The simple plugin interface proposed here should permit this. One  
thing it doesn't do is disable SCM menu items based on the state of  
the file.

It's possible to implement this same interface with scripts, one  
could set a "this is a VCS" bit in the version control bundles, and  
have special hook scripts for "Is this in your version control  
system", "What state is this file in", etc, but I wonder about  
performance. It wouldn't be as efficient; would it be good enough,  
though? The real performance hit for remote SCM is the network query,  
so probably it would be fine.

// bitmap
typedef UInt32 TMSCMState;
enum
{
     kTMVCReadOnly = 0x01,                // Some VC systems need you  
to explicitly unlock the file for editing, this is the locked state  
for that case
     kTMVCModifiable = 0x02,
     kTMVCExclusiveLocked = 0x04,    // if exclusive locked by the  
current user, state is kTMVCModifiable | kTMVCModifiable
     kTMVCLocallyModified = 0x08,
     kTMVCServerModified = etc,      // newer rev of this file on server
     kTMVCUnknown                // this file is not known to the VC
     kTMVCIgnored                // this file is known but ignored by  
the VC (svn:ignore)

// Distributed VCS systems (such as Darcs, Arch, git, baz,  
Mercurial...) will probably only return Modifiable or LocallyModified.
};

@interface TMVCController
- (void) registerVC:(id<TMVCSystem>) vc;
@end

@protocol TMVCSystem
- (NSString *) VCBundleID;    // GUID for the version control bundle  
used to populate the context menu
- (BOOL) isUnderVCControl:(NSURL *)folderPath;    // query to  
determine if this is the right VC system for the given folder
- (TMVCState) stateForLocation:(NSURL *)fileOrFolder;
@end

@implementation TMVCSubversion
- (BOOL) underVCControl:(NSURL *)path
{
     // braindead implementation, not future-proof
     return [... fileExistsAtPath:[path  
stringByAppendingPath:@"/.svn"]];
}
@end



From throw-away-1 at macromates.com  Sat Oct 29 17:48:32 2005
From: throw-away-1 at macromates.com (Allan Odgaard)
Date: Sat, 29 Oct 2005 19:48:32 +0200
Subject: [TxMt Plugins] Version Control Plugins
In-Reply-To: <79C3FD7C-A924-47FA-AA84-62F4B900CB0B@cjack.com>
References: <79C3FD7C-A924-47FA-AA84-62F4B900CB0B@cjack.com>
Message-ID: <6D3B591A-FB82-47D2-BB63-8791B6572146@macromates.com>

On 28/10/2005, at 16.19, Chris Thomas wrote:


> Just some quick notes while I'm idly thinking about this.
> ...
> For maximum flexibility, probably most version control operations  
> should still be handled through the current bundle system. However,  
> there are two very desirable things we can't do with the bundles:
>
> (1) a context-sensitive version control menu (perhaps a "Version  
> Control" submenu for the context menu)
> (2) a graphical indication for each file of the current version  
> control state - another icon in the newly mousable status bar :) [...]
>

It requires a little more work from the plug-in, but how about  
something like:

    // callbacks/notifications the plug-in can subscribe to
    open file
    show/hide file (for tabs)
    save file (sending both will/did save)
    close file (maybe open/close should just be sent when switching  
tab to minimize the API)

I think these notifications would be useful for Gerts code browser  
plug-in as well, and could also be used to make save hooks.

Now, for the visualization of SCM I'd propose doing it “push” style,  
and e.g. have a (simple) API to add/remove a cell (NSCell) to/from  
the status bar. That way the plug-in can add a cell that displays svn  
status, but could also add something completely different, like a  
function drop down :), a toggle that enables/disables the save hook etc.

For the context menu, I'd suggest a callback like “will show context/ 
action menu for file”. This should again allow arbitrary actions to  
be added to the menu.

As for shell commands, I'd do one last method (added to the plug-in  
controller) which allows executing a bundle item (given by UUID) in  
the context of (a) file. So a SCM system could populate the context  
menu with actions that actually just wraps for the bundle items (it  
would be logical to add a PlugIns folder to the bundles, and allow  
the user to enable/disable plug-ins per bundle in the BE, but e.g.  
for svn, it would be enabled but just stay passive for files not  
under svn control).




From throw-away-1 at macromates.com  Sat Oct 29 18:02:51 2005
From: throw-away-1 at macromates.com (Allan Odgaard)
Date: Sat, 29 Oct 2005 20:02:51 +0200
Subject: [TxMt Plugins] Version Control Plugins
In-Reply-To: <6D3B591A-FB82-47D2-BB63-8791B6572146@macromates.com>
References: <79C3FD7C-A924-47FA-AA84-62F4B900CB0B@cjack.com>
	<6D3B591A-FB82-47D2-BB63-8791B6572146@macromates.com>
Message-ID: <B861E5CF-8917-4423-AE26-600B1F14863E@macromates.com>

On 29/10/2005, at 19.48, Allan Odgaard wrote:

> [...] would be useful for Gerts code browser plug-in [...]

Sorry, that should have been Gerds plug-in :)



From chris at cjack.com  Sat Oct 29 23:58:04 2005
From: chris at cjack.com (Chris Thomas)
Date: Sat, 29 Oct 2005 19:58:04 -0400
Subject: [TxMt Plugins] Version Control Plugins
In-Reply-To: <6D3B591A-FB82-47D2-BB63-8791B6572146@macromates.com>
References: <79C3FD7C-A924-47FA-AA84-62F4B900CB0B@cjack.com>
	<6D3B591A-FB82-47D2-BB63-8791B6572146@macromates.com>
Message-ID: <0E4CC576-09D3-40EC-8DFC-43464DBABD38@cjack.com>


On Oct 29, 2005, at 1:48 PM, Allan Odgaard wrote:

> It requires a little more work from the plug-in, but how about  
> something like:
>
>    // callbacks/notifications the plug-in can subscribe to
>    open file
>    show/hide file (for tabs)
>    save file (sending both will/did save)
>    close file (maybe open/close should just be sent when switching  
> tab to minimize the API)

Ah, I like it. I suspect you may ultimately want open/close and show/ 
hide to be separate. I can see caching data between open and close  
that I wouldn't necessarily want to throw out on hide, for example.  
But maybe not.

> Now, for the visualization of SCM I'd propose doing it “push”  
> style, and e.g. have a (simple) API to add/remove a cell (NSCell)  
> to/from the status bar. That way the plug-in can add a cell that  
> displays svn status, but could also add something completely  
> different, like a function drop down :), a toggle that enables/ 
> disables the save hook etc.

I like that very much. Sounds perfect, except for one thing: there  
will inevitably be user requests to display the status of each item  
in the drawer next to the filename, whether or not the file is open.  
I guess one could handle that by adding a "files loaded into drawer"  
callback, and perhaps allowing each filename to be adorned with a set  
of NSImages.

> As for shell commands, I'd do one last method (added to the plug-in  
> controller) which allows executing a bundle item (given by UUID) in  
> the context of (a) file. So a SCM system could populate the context  
> menu with actions that actually just wraps for the bundle items (it  
> would be logical to add a PlugIns folder to the bundles, and allow  
> the user to enable/disable plug-ins per bundle in the BE, but e.g.  
> for svn, it would be enabled but just stay passive for files not  
> under svn control).

Ship it. Wicked cool.

Chris