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

Re: [TSVN] Proposal for code modification

From: SteveKing <stefankueng_at_gmail.com>
Date: 2004-12-22 12:00:42 CET

On Wed, 22 Dec 2004 08:49:59 +0000, Will Dean <svn@indcomp.co.uk> wrote:

> I am finding that the joys of "str.Replace('\\', '/')" are wearing rather
> thin. I don't want to type it, and I don't want to read it.

me neither ;)

> TSVN is *stuffed* with path manipulation code - this is partly because
> there is a genuine difficulty with the need to handle paths in at least
> three forms on the UNICODE build and, I think, partly because at the outset
> no-one realised what a pain that was going to be, and so paths have been
> handled as adhoc strings.
> There is lots of evidence that people are often not quite sure what type of
> path a function might be called with, so re-run things like
> str.Replace('\\', '/') just in case they're needed. There are some
> general 'preparePath' sort of functions, but they're not used everywhere,
> and I suspect they would cause a perf problem if they were.

There's one in the SVN class, which is called from almost every method
in that class, just before calling the svn_client_xxx() functions.

> I would like to propose that we (that's me) added a class, called something
> like CTSVNPath, or CTSVNFilename.

CTSVNPath is better - that could be a file _or_ a folder.

> This would encapsulate a path, and would be able to return a number of
> different forms of path - Windows API compatible, SVN compatible, SVN
> compatible, etc. I would take the appropriate steps to maintain
> performance, probably by holding multiple copies of the pathname in
> different forms, as required. There would also be accessor functions to
> get the name and the extension of the path, and to find out if the path
> represented a file or a directory.
> If we wanted to do highly optimised path compare functions, this would also
> be the place to do it.
> We would (eventually) store *all* path strings in this class, converting to
> and from API-compliant types (TCHAR*, char*) only at the boundaries of APIs.
> The main thing I think we would get from this class would be code
> simplification, and hopefully an increase in robustness. I think there
> *might* be some small perf benefit, but that's not certain. The amount of
> memory used storing paths would almost certainly increase, but I don't
> think that's a big deal.
> What do people think?

I like the idea. We could even go a step further and include URL's in
that class too. Then depending on svn_path_is_url() (or our own
checking function) we could then return the appropriate string. For
urls, beside UTF8 conversion there's escaping.
Oh, and check out the methods MakeSVNUrlOrPath and MakeUIUrlOrPath.


To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Dec 22 13:18:20 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.