[SVN] r7480 (Git)

[Allan Odgaard]

On 12. Jun 2007, at 02:11, Chris Thomas wrote:

> Some quick, broad comments:
>
> - Subversion++ is a great idea -- I'd use this capability regularly
> - Git bundle is a great idea
> - More sharing is abstractly a great idea
>
>> Selection: Most commands have logic to check if there is a  
>> selection (and then various variations of how to decode  
>> TM_SELECTED_FILES into an array), a project folder, a current  
>> directory, etc.
>
> Maybe this should be higher level than SCM?

Yeah, I think you’re right. I btw forgot to mention one other twist  
on the selection logic: filtering out selected files in selected  
folders.

>> Paths: Paths need to be pretty printed, that means, if we run on  
>> the project folder, they should be relative to this one, if we run  
>> on a selection, preferably they should be relative to the nearest  
>> common ancestor of the selection, finally they should fall back to  
>> being shown with the home folder abbreviated using a tilde — many  
>> commands presently have some custom logic that sort of does the  
>> above (but not quite, and each one re-invents the wheel).
> This, too, might be useful at a higher level than SCM.

Agree, yes.

I’ll try to come up with some good names for these modules. I think  
we need two-level namespaces like we did with TextMate::UI, otherwise  
we’ll end with hundreds of methods under TextMate.

>> Status: I know many svn commands have their own mapping of letter  
>> → status text and foreground/background color. This should be  
>> encapsulated into a SCM::Status class where instances are mostly  
>> created by name (and can then be queried about color, etc.)
> I haven't tried to fix this in the past because the solution would  
> have to somehow map into Objective-C for the commit window. A  
> tm_dialog-based commit window will simplify the task, but some code  
> probably needs to be integrated into the dialog plugin. Bindings  
> fixes in Leopard may make this easier.

Yes, I think we need to introduce a system for lazy-loading classes,  
i.e. so we can have more advanced stuff “part of TM” but not  
suffering from having to always load it at startup. Presumably many  
of the current plug-ins could also benefit from lazy-loading  
(probably giving a menu item “trigger” in their Info.plist).

> A related question... how is this going to map into TM 2.x? Will  
> 2.0 allow bundles to annotate files in the project view?

Yes, my current model is that anyone can set attributes on files.

These attributes can be used to change the rendering of files and  
also becomes part of the file’s scope -- so in practice there is a  
svn handler which is notified about which files are opened and shown  
in the file browser, and it will fetch svn status for these and set  
“scm.svn” for all files under svn control,  
“scm.status.modified” for those which are modified, etc.

In the scope “attr.” is added as a prefix and we can thus set the  
scope selector for all the commands in the Subversion bundle to  
“attr.scm.svn” (and have the same activation key for all SCM  
systems). Additionally we can inject the diff grammar into  
“attr.scm.status.conflict”, etc.

So basically there is only one new thing related to SCM integration  
(and it’s not specifically tied to SCM), though it will also be  
possible to associate action menus to files (ideal for SCM also). But  
the current command-driven system for handling SCM will be the same,  
and so we can re-use the current stuff, we just need to write a  
status-handler for each SCM system (to annotate files) plus setup an  
action menu.