The problem is that a context menu outside of Tortoise would need to
know about the working version to pass such information to the
plugin. Hence would duplicate functions already inside TSVN and thus
require the whole SVN API.
My suggesion is to provide some means of extending the functionaltiy
of Tortoise through a plugin API.
A third party application would add its context menu to that of TSVN
and when run from explorer would be passed information such as repo
path, current version, modified etc. without any need to understand
how to talk SVN.
For example, in my example above, the plugin, through the context menu
would create a batch file that contains information about the repo
path and version of the folder. This batch file is all that is checked
into the foreign repository. e.g. "Run me to retrieve from SVN.bat"
Thus users only running TSVN or SVN would still be able to checkout,
even without a plugin. Users without SVN or TSVN would be prompted
to install it, no other software is required.
Only the individual creating the 'tag' of the SVN working version in
the foreign system needs the plugin.
Surely such a means of allowing adoption of SVN & TSVN without
scrapping existing systems overnight should be high on the must have
list in order to gain SVN adoption?
A plugin API would allow this and enable other programmers to add
features that they consider absent from TSVN, without relying or
waitng for that feature to be built in.
On Sep 8, 5:07 pm, Stefan Küng <tortoise..._at_gmail.com> wrote:
> the-moog wrote:
> > hi,
> > I would like to provide users with the ability to see that an SVN
> > repository is available for a given folder.
> > The purpose of this is to integrate SVN with MKS, a third party
> > revision control system. Though my suggested solution has other uses.
> > The idea would work as follows:
> > On the TortoiseSVN context menu, as well as EXPORT, there would be an
> > EXPORT-LINK menu item.
> > Clicking this this would create an executible or batch file in the
> > target location that would run nativley on Windows. The link file
> > would contain code that would perform as follows:
> > 1: If ToroiseSVN is installed, then TortoiseSVN would be used to
> > check out the target given in the link into the current folder.
> > 2: If Tortoise is not installed, but SVN is, then SVN client would
> > be used to do the same.
> > 3: If neither is installed, then a dialog would explain that
> > TortoiseSVN or SVN client is missing and must be installed.
> > As well as the target, the link file would contain metadata on how to
> > check out that link, e.g. include exernals, sparse checkout etc.
> > This executible 'link' could be checked into the third party revision
> > control system. In this case, this system is MKS as it has very poor
> > handling of folders and file attributes, unlike SVN. Such a system
> > would allow adopting of SVN without having to immediately obsolete
> > MKS.
> > An extension to this would be to allow signing of the link executible
> > to ensure that the link file is genuine.
> > Perhaps the simplest way to implement this would be to allow some
> > means of extending Tortoise menu through plugins, and hand over the
> > above functionality to another program.
> > How easy would it be to make changes to TortoiseSVN to allow a third
> > party program to modify its context menu?
> Such a context menu entry wouldn't require any feature from TSVN itself.
> So I suggest you just implement your own context menu handler for this.
> The TSVN context menu is not extensible, but the Explorer context menu is.
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
> < 1KViewDownload- Hide quoted text -
> - Show quoted text -
To unsubscribe, e-mail: dev-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: dev-help_at_tortoisesvn.tigris.org
Received on 2008-09-09 13:39:21 CEST