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

Re: [BUG] The client can't use a different directory than .svn

From: Landon Clark <gmane_at_lclark.net>
Date: 2003-12-10 18:54:37 CET

Greg Hudson wrote:

> On Wed, 2003-12-10 at 03:18, Lübbe Onken wrote:
>>I'm glad I hear some agreement here, because I remember the last thread
>>ending nowhere, with some suggestions hanging around, but no agreement
>>how this problem could be solved.
>>Now we have:
>>- a possible suggestion
>>- an agreement :-)
>>- a time schedule (post 1.0) ;-)
> Don't be too optimistic here; I don't really agree with a change.
> Here's my opinion:
> * There will always be environments for which svn is useless. We're
> mostly useless for versioning Interface Builder projects because we
> don't have collection support. We're mostly useless for projects like
> the Linux kernel, which require a distributed versioning system which
> can handle a high throughput of patches. (I don't agree with how those
> projects are organized, and svk will help.) And apparently we're useless
> for ASP.NET projects too.
> * While we should generally be tolerant of platform bugs, we need to
> balance that against the short-term and long-term pain of allowing for
> them, and the number of people affected.
> * Kevin claims that this problem will eventually be fixed in Visual
> Studio, when the next version comes out. But the proposed change would
> hang around and create maintenance and support hassles forever.

I am really, really, really, really sad to hear this. While I
understand the sentiments above, I would like to try to make the case
one more time. I am not advocating a the entire multiple acceptably
named directories change, just a patch to change the name of the of the
svn admin directory on Windows.

First, SVN is not useless to Linux kernel development. They choose to
use another tool because it supports a set a features they wanted. If
they had to, they COULD use svn. Nothing is stopping them. This is not
the case with ASP.net.

Second, SVN has a stated goal of replacing CVS. I don't know much about
Interface Builder, but I bet that CVS has the same problem with it that
SVN has. In the case of ASP.net projects, SVN is worse than CVS
(meaning pretty much unusable).

I would also guess that there are quite a few more IIS / VS users than
Interface Builder users but number of users is not always a driving
concern. Also, the change to support "collections" in SVN is FAR larger
than the change to support VS and IIS. That means that the work to
reward ratio is much higher.

I would also like to mention that the choice of .svn as a name, though
logical, is arbitrary. It could have been SVN (like CVS), or _SVN, or

Finally, I think that losing the feature of moving WC across platforms
is a fair tradeoff for allowing users of one of the most popular
software development platforms in the world (and trust me I wish it
wasn't) to use svn.

"eventually fixed by Visual Studio" does nothing for those of us who
*have* to use ASP.net and *want* to use SVN today. Don't get me wrong,
  I blame microsoft for this problem. But I am so passionate about this
because I have been using SVN for all my work since version .14. I just
changed jobs and I have a need to support ASP.net projects and thus it
looks like I will have to give up SVN. I cannot begin to tell you how
much that pains me.

Please consider all of this when making a final decision about whether
to make this change.

Thanks for reading,

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 10 19:01:28 2003

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.