[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Feature request: SVNLinks

From: Simon Large <simon.tortoisesvn_at_googlemail.com>
Date: Tue, 9 Sep 2008 14:06:43 +0100

2008/9/9 the-moog <jason.morgan_at_cropwell.net>:
> Thanks Stefan,
>
> 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.

All that information is available from the svn command line tools.
Create a batch file that takes the working copy path and let svn work
out the rest. Or create a C/Delphi/Java/... app which calls the
command line interface or uses the SVN bindings or whatever, and add
that to the context menu.

> 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.

Let me get this straight. You want us to write a plugin system for
TSVN so that one person in one organisation can be spared calling a
batch file a few times?

> 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?

So users of the foreign repository now find that it contains a single
batchfile which they have to checkout, then run to do an SVN checkout?
That implies that you moved the foreign repository content to SVN and
deleted it from the original repository. How is that not an overnight
scrapping of the foreign system?

> 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.

They can do that now. It's an open source project.

Simon

-- 
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
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 15:06:57 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.