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

Re: Space wasting

From: Adal Chiriliuc <adal_at_myrealbox.com>
Date: 2004-03-08 21:59:28 CET

On Monday, March 8, 2004 Greg Hudson wrote:
> Moreover, this proposed change seems totally orthogonal to fixing the
> asp.net problem. We could put the entire administrative area in a file
> (rather than a directory) named .svn, and Visual Studio would remain
> broken (until Microsoft fixes it, which is actually expected to happen
> in the next release). We could move the administrative area to a
> directory with a different name, and Visual Studio would no longer have
> a problem. We aren't likely to do either, though.

Visual Studio 6.0 was released in 1998. It still is the predominant VC
version out there. The Service Pack 5 update for this is one of the most
downloaded items from Microsoft site.

The lesson is that even if Visual Studio .NET 2003 is a huge improve,
people are slow to update. Hell, I also use Visual Studio 6.0. So
waiting for users to switch to Whidby (the next version) is a bad
decision. I think this issue should be fixed somehow.

Why? It is bad PR to refuse to do a workaround for the IDE which will
become the predominant one in Windows. People could start talking that
Subversion developers don't care that much about Visual Studio support.

I agree that it's Microsoft problem, but bad word of mouth is very
dangerous.

If you care about Win32/Visual Studio you should "fix" this.

After all, it's not like you have to rewrite the hole program. One
%APPDATA% configuration option will do.

Adal Chiriliuc

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 8 22:01:11 2004

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

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