On Sep 16, 2005, at 02:39, Paul Coddington wrote:
> 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.
You don't need anything custom. It's built into Subversion; it's
called svn export.
> * 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.
Get a better editor or command-line utility, or request that your
editor or command-line utility be updated to deal with this problem.
For command-line utilities, actually, I can't believe there would be
any problem, since they're usually designed to be very flexible and
to work well with other command-line utilities. For example, under a
Unix-like operating system, I would expect that you could use find or
grep to gather a list of files on which you want to operate (which
would exclude those in the .svn directories) and then send that list
to your command-line utility that does the actual work. I'm not
familiar with command-line utilities on Windows, though; maybe
they're more limited.
> * 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.
Can't say anything about VS.NET; don't know it. To the question "why
would I want my .SVN folders to be published on my webserver in the
first place?" the answer is that you wouldn't—at least, you wouldn't
want them published within the web space, accessible to outsiders. To
prevent that, you could svn export, as mentioned above, and point
Apache to the exported folder, or you could point Apache directly at
the working copy, with the .svn folders intact, and use an Apache
rule to deny access to them. Works just as well. By using a working
copy, though, you can transfer only the changed files from the
repository to the web server, rather than having to export the whole
thing every time you want to do an update.
I described how we handle this in our company some months ago; it may
be relevant to you:
http://svn.haxx.se/users/archive-2005-06/1754.shtml
We actually have a snazzy script that we use on the live server to
handle the switches and exports. It's pretty full-featured since it
got overhauled yesterday, but I'm not sure if it's ready to be shared
yet. If anyone would be interested, you can let me know off-list and
I'll look into it.
> 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.
You would not want to have the tags checked out into your working
area, since you never work on tags. Tags, once created, are not
supposed to change. That's not enforced by Subversion, of course
(unless you write a pre-commit hook to do so) but it's a useful
convention.
I'm not sure why you think that specifically TortoiseSVN assumes that
you have only a single working area that you switch from trunk to
branches. From reading the Subversion Book, I get the impression that
this is the suggested way to work regardless of what client you use.
Despite this, I have yet to try working this way. Instead, I always
have a working copy of trunk (or sometimes 2 or 3, if I'm working on
2 or 3 tasks at once), and another working copy of the latest
released branch, which I can merge my trunk changes into if desired.
When that release branch goes obsolete and a new release branch
starts being used, I svn switch my branch working copy to the new
release branch.
I'm going to try to force myself to do it the way the Book suggests,
though, because for two of our projects, the working copies are large
(the largest working copy is 228MB in 40038 directories). And it's
excrutiating having that stuff swap in and out of the disk cache all
the time.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Sep 17 11:35:46 2005