Some food for thought regarding your excellent products.
Disclaimer: If I have missed some obvious feature that makes these issues perceived rather than real, bear in mind that I am the newbie to Subversion who is enjoying every moment of using it and rejoicing in the new found opportunity to avoid the limitations of Visual SourceSafe (;P) So, if I am mistaken, have a private giggle at my expense and we'll all move on (although it may also provide some thought for future amendments to the Subversion manual to clarify some points).
Suggested Feature:
The ability to optionally specify a local SVN reference folder in which all .SVN folder based information normally stored in the working folder is stored as a single tree, completely independant of the working folder (effectively a local per-user database). This would be particulary useful for Win32 clients, with the default being a folder in Local Settings\Application Data for the current user. However, the drawbacks with the current implementation that this proposal seeks to resolve are likely to be cross-platform.
Scenarios:
This suggestion, if implemented, would alleviate this list of issues:
* The problem of how to copy a project without including the .SVN folders, for example, detaching the project from source code control for XCopy distribution and installation. At this time, the project must be copied to an intermediate folder and custom scripts must be written to delete the .SVN folders.
* The problem that a number of command line utilities and developer editors performing bulk search and replace operations will corrupt the .SVN folder content (as being hidden does not prevent them from being acted upon and many tools have no option to avoid acting on hidden files and folders). For example, global removal of comments from SQL Server scripts on *.* in a folder tree also modifies reference copies in the .SVN folder. Specifying individual extensions solves the issue, but there are a number of individual extensions to take care of one at a time, increasing the risk of error or ommission.
* The problem that some tools, such as VS.NET do not like having .SVN folders in the project tree. (Rather than see this as a bug, one should also ask 'why would I want my .SVN folders to be published on my webserver in the first place?'). This way, everyone can use '.SVN', without resorting to unreasonable workarounds or using '_svn' and being incompatible with others.
Another suggestion: it would be nice to be able to check out an entire repository and have an option to automatically obtain the root or a named branch (that is, said information is stripped from URL automatically). TortoiseSVN seems to operate on the assumption that you do not have a 'trunk/branches/tags' structure in your working folders, but rather you 'switch' a single project folder between them. However, this means you can not check out an entire repository in one hit, but rather must do it bit by bit, otherwise you end up with the 'trunk/branches/tags' folders in your working folder tree.
regards
PAUL CODDINGTON
IT Development, PASAD
Centacare Archdiocese of Canberra and Goulburn
P.O. Box 3167
Manuka ACT 2603
Phone: +61 (2) 6295-4323
Fax: +61 (2) 6239-7171
E-mail: paul.coddington@centacare-canberra.org <mailto:paul.coddington@centacare-canberra.org>
Received on Fri Sep 16 13:08:13 2005