You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Paul Coddington <Pa...@centacare-canberra.org> on 2005/09/16 00:39:47 UTC
Feature Suggestion: Ability to specify dedicate path for .SVN folders.
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 <ma...@centacare-canberra.org>
Re: Feature Suggestion: Ability to specify dedicate path for .SVN folders.
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 9/15/05, Paul Coddington <Pa...@centacare-canberra.org> wrote:
> 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 svn export command is generally intended to be to solution to that
particular problem.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Feature Suggestion: Ability to specify dedicate path for .SVN folders.
Posted by Ryan Schmidt <su...@ryandesign.com>.
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
Re: Feature Suggestion: Ability to specify dedicate path for .SVN folders.
Posted by Kyle Kline <ky...@gmail.com>.
Workaround for .svn folders + VS.NET <http://VS.NET> web projects:
http://subversion.tigris.org/faq.html#vs-asp-net
and
http://pluralsight.com/wiki/default.aspx/Fritz/AspNetWithoutWebProjects.html
My team uses the "convert to local class projects" option - this works
*great*, and you will actually find it has value aside from the .svn issue
workaround with VS.NET <http://VS.NET> (less configuration headaches.)
On 9/17/05, Ryan Schmidt <su...@ryandesign.com> wrote:
>
>
> 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.
>
> I meant also to say: this proposal would cause the following new issues:
>
> If you store each working copy's .svn data in Local Settings
> \Application Data, then presumably you have to link it with the
> actual location of the working copy somehow. If you do this by path,
> then it is not possible to move or rename a working copy; this is
> possible with the current implementation, so this would be a
> reduction in functionality.
>
> If, to allow moving and renaming working copies, you only store some
> sort of working copy ID in the Application Data (and not its path),
> then you still cannot (easily) give a working copy to another user on
> your machine, or on another machine. This is currently possible, so
> this would be a reduction in functionality as well.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: Feature Suggestion: Ability to specify dedicate path for .SVN folders.
Posted by Ryan Schmidt <su...@ryandesign.com>.
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.
I meant also to say: this proposal would cause the following new issues:
If you store each working copy's .svn data in Local Settings
\Application Data, then presumably you have to link it with the
actual location of the working copy somehow. If you do this by path,
then it is not possible to move or rename a working copy; this is
possible with the current implementation, so this would be a
reduction in functionality.
If, to allow moving and renaming working copies, you only store some
sort of working copy ID in the Application Data (and not its path),
then you still cannot (easily) give a working copy to another user on
your machine, or on another machine. This is currently possible, so
this would be a reduction in functionality as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org