Workaround for .svn folders + VS.NET <http://VS.NET> web projects:
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 <firstname.lastname@example.org> 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: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Sep 18 17:47:50 2005