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

Re: CHANGE REQUEST: support for linked files, repository property searches

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2007-09-05 18:50:43 CEST

Andrew Mayo wrote:
> May I say that TSVN is a very nice piece of work, and a joy to use....
> A couple of change requests I would like to suggest, if I may...
> 1. Although I appreciate that (sorta) SVN:EXTERNAL and Unix symlinks can
> help here, what would really be useful is the ability to link files or
> directories together to allow the same component to be 'symbolically
> linked' inside the repository to multiple folder locations.
> In this context, revisions to a linked component would affect all linked
> copies. The browser, ideally, would distinguish linked items with a
> unique icon, and enable the user to determine the linked paths to all
> other occurrences of the linked item.
> This functionality would permit multiple tree views to be established on
> a common repository. This is most useful when using SVN as a
> documentation control system rather than specifically for source code
> control and allows different audiences to view the information in
> different ways e.g by customer, by release etc. but still retain a
> common revision history. At present you can of course copy the tree but
> you then lose coherent history as soon as the copy is updated.

That would require a change in the Subversion library. You have to ask
on the Subversion mailing list for such a feature.
One thing you should know is that you will never be able to link
*files*, only folders. And for that, I think svn:externals should be enough?

> 2. The ability to search the repository from the repo-browser for a
> specific property and value would greatly increase the utility of this
> feature. This would be a recursive search from the selected root folder,
> and ideally allow wild cards or regular expressions for both property
> name and value, as well as possibly the ability to define a search time
> as a boolean against more than one property or value.

To get a property for a file/folder, a request has to be made to the
repository. Searching a whole repository would last forever (just
estimate about a second for every file and every folder).

> I note in this context that 'search log' cannot (afaik) recurse and this
> also would be very useful to enhance, so that the log could be
> recursively searched from any root folder selected as the starting point.

The log is always shown 'recursively'. For example, if you show the log
for the working copy root (usually /trunk), you will get all changes of
that folder including all changes in files/folders below that folder.
But of course, the log doesn't show you which properties have changed,
only that properties have changed (not which ones exactly).

> Ideally, the browser should also permit full text search on the tree.
> Since many files are binary, this would have to work a bit like DIFF in
> that you would need to specify a 'grep' command that works for each file
> type; any file for which this doesn't exist will not be searchable. Then
> the browser will recurse from the selected root, invoking the specified
> 'grep' for each item found,. and collating the results so that you can
> then select any component from the search result list.

That would bring the server down to its knees if a client like TSVN
would fetch every file from the repository and search it for some
strings. Even worse if you want it to also search the history of each file.

> These changes greatly augment the use of SVN as a documentation control
> system, for which it is well suited. They are also useful in a source
> code control context but anyone managing source code also has tons of
> specs and other documents that SVN would manage very well - these extra
> features would make it a killer application for documentation management.

While I fully agree with you that these would be nice features, they're
outside of TSVN's control. Such features would have to be implemented in
the Subversion library, including some major enhancements on the server
side. That means you would have to ask on the Subversion mailing list
for those features.


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Wed Sep 5 18:47:52 2007

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