Determining Whether to Implement a Source Control VSPackage
This section elaborates the choices of source control plug-ins and source control VSPackages for extending source control solutions and gives broad guidelines about choosing a suitable integration path.
If you have limited resources and cannot be burdened with the overhead of writing a source control package, you can create Source Control Plug-in API-based plug-ins. This allows you to work side by side with source control packages, and you can switch between source control plug-ins and packages on demand. For more information, see Registration and Selection (Source Control VSPackage).
If you want to implement a source control solution that provides a rich source control model that is not adequately captured by using the Source Control Plug-in API, you may consider a source control package as the integration path. This applies especially if you would rather replace the Source Control Adapter Package (which communicates with source control plug-ins and provides a basic source control UI) with your own so that you can handle the source control events in a custom manner. If you already have a satisfactory source control UI and want to preserve that experience in Visual Studio, the source control package option lets you do just that. The source control package is not generic and is designed solely for use with Visual Studio IDE.
If you want to implement a source control solution that provides flexibility and richer control over the source control logic and UI, you may prefer the source control package integration route. You can:
Register your own source control VSPackage (see Registration and Selection (Source Control VSPackage)).
Replace the default source control UI with your custom UI (see Custom User Interface (Source Control VSPackage)).
Specify glyphs to be used and handle Solution Explorer glyph events (see Glyph Control (Source Control VSPackage)).
Handle Query Edit and Query Save events (see Query Edit Query Save (Source Control VSPackage)).