Stefan Küng wrote:
> Ben Summers wrote:
> >
> > Hello!
> >
> > Thanks for all the hard work on TortoiseSVN. I'm using it as a
> front end
> > for SVN for a group of about 10 non-technical users who use it to
> > collaborate on a 12Gb collection of binary documents, mainly in MS
> > Office formats. It works really well with only a small amount of
> > training, which is pretty impressive for a front end to a source
> control
> > system aimed at software developers.
> >
> > In relation to this non-standard use, I need to implement a
> couple of
> > features. I thought I would do this in a general enough manner to
> get
> > them accepted into the main source tree, and hope you'll help with
> > commenting on my plan and perhaps pointing me to appropriate bits
> of the
> > code.
> >
> >
> > These features are about making round trips to and from a web
> > application with minimal fuss:
> >
> > 1) Right click menu to open a URL: The user right clicks on the
> file in
> > Explorer, and chooses 'Open in X'. TortoiseSVN opens a URL into
> which
> > are substituted the repository URL, name, path etc.
> >
> > 2) Clicking on a link in the web site opens a Windows Explorer
> window
> > with the selected file highlighted. If it's not checked out on disc,
> > offer to check out the parent folder.
> >
> >
> > For the implementation, I'm thinking along the lines of
> >
> > 1) For the context menu, use something similar to "Integration with
> > Bugtracking Systems". A property would be read from the root of the
> > repository with name tsvn:contextmenu. This contains | separated
> pairs
> > of menu entry name and URL. The URL contains substitution markers
> such
> > as %URL%, %REPOSITORY%, %PATH%. For example, to add a 'View in Trac'
> > menu entry, I would set the property to
> >
> > View in Trac|http://example.com/project/browser/%PATH%
> >
> > I would see this menu entry below the SVN Update context menu
> entry, and
> > choosing it would open a web browser window for the file or
> folder in Trac.
> >
> > In this case I need to be able to set the properly on the root
> and have
> > it work everywhere below, even if the user has checked out a
> subfolder
> > or created new files. Because of the size of the repositories,
> the users
> > don't check out everything, and they certainly won't be able to
> apply
> > the properties to the new folders they create. I think that
> > ProjectProperties will recurse downwards to find them in
> > ReadPropsPathList(), but not below folders which are checked out. If
> > this is right, what's the best way of reading it from the
> repository root?
>
> Please check the docs for project properties. They can be applied to
> every folder (and in TSVN 1.5 they're added automatically when a
> folder
> is added to version control).
Sounds perfect.
> You must not contact the repository from a shell extension. If the
> server is down or even just slow, the whole shell will hang/block -
> which makes the user very, very angry.
> If you really want to contact the repository to ask for that
> information, then you will have to implement your own shell extension.
> I'm sorry, but I can't accept such a feature in TSVN and risk blocking
> the whole system.
I was imagining reading it in the background and caching it, for
precisely that reason.
>
> > To add the menu entries, I think I would need to add a small
> number of
> > entries to the list in TortoiseShell/ContextMenu.cpp, and then
> when the
> > menu is opened show or hide them and set the text label
> appropriately.
> > There may be some fun and games to transfer the necessary
> information to
> > and from the cache process.
>
> You don't have to cache those. Reading project properties would be
> quite
> fast - fast enough to do that in the context menu handler.
> Or at least, I would try it that way first and see how the performance
> is. If it's bad, you can then change the cache to also include those
> properties.
>
> And I would implement a function which reads the props, extracts the
> names for the menu entries and then add those entries dynamically.
> Don't
> add menus and then 'hide' them if they're not needed.
I'm not that up on shell extensions nor the code. I see the entries
are added each time the menu is opened, so that hack won't be necessary.
>
> >
> > An alternative implementation is to add some registry entries which
> > allow it to be set up globally for all repositories. This would
> do fine
> > for me, but is less general and so less useful to the project.
>
> But much easier to do: a simple registry entry can already show a
> context menu, even without a shell extension. Just read the docs in
> the
> MSDN.
> As an example, think of all the text editors which add an 'open with
> mytexteditor' for every file. You could write a small program or even
> script which would create the URL to open from the selected file and
> then open the browser - that could be implemented in a few minutes.
You are indeed correct.
The only way I can see to find the URL given a file on disc is to use
SubWCRev with an input file of $WCURL$ and then read the output file.
It does work, but is there a more elegant way without installing a
separate SVN binary?
>
> > 2) With the URL scheme for clicking a link in a web page, I'd
> extend the
> > tsvn: url scheme handler. It seems as reasonable as anything to
> add a
> > URL style parameter, as SVN itself doesn't use them. So
> > ?tsvnaction=locate appended to the URL would do the trick.
> >
> > tsvn:http://example.com/repo/path/to/file.txt?tsvnaction=locate
> >
> > Implementing it is harder, because I don't think there's a store
> of all
> > checked out repositories. A possible implementation is to get
> TSVNCache
> > to record the repositories it's seen in the Registry, and then run
> > through them testing to see if they still exist when the request is
> > received. As I understand it, the URL gets passed to TortoiseProc
> with
> > /command:checkout. I can either modify the checkout command, or
> add a
> > new one for handling the URL which may be a bit neater.
>
> What happens if someone has the same folder checked out twice? Which
> location would you then use?
>
> Since this operation won't happen very often, it wouldn't matter if it
> would take a few seconds to find the file from the URL. So I guess
> a new
> function in the cache which would find a local path for a given URL
> would do the trick here. But the problem persists: what to do when an
> URL matches multiple local paths?
I suppose you give them a choice in a pop up dialogue. In this
particular use case they're unlikely to have multiple checkouts, but
obviously this is common for developers.
>
> > I presume that I can start coding by installing the latest Visual
> Studio
> > Express from http://msdn2.microsoft.com/en-us/express/
> aa700735.aspx . I
> > suspect my copy of Visual C++ 6.0 is a bit on the old side,
> hopefully
> > the new one won't clash.
>
> VSExpress won't do the trick here, sorry. Because the express edition
> doesn't come with the MFC/ATL libraries which we use in TSVN.
> You can only compile some sub projects of TSVN with the express
> edition:
> TortoiseBlame, CrashRpt, ResText, SubWCRev, TortoiseIDiff,
> TortoiseUDiff.
>
> You will need the professional edition of VS to compile TSVNCache and
> TortoiseProc.
That's a helpful omission from Microsoft.
It sounds like the best way forward is for me to implement the
features outside TortoiseSVN, then perhaps release them as an
separate add-on. If there's any interest they could be implemented
nicely inside TSVN later.
Thanks for your help! You've probably saved me a lot of work by
suggesting something isn't done.
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Sep 6 19:54:39 2007