[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: Lübbe Onken <l.onken_at_rac.de>
Date: 2003-12-09 16:55:24 CET

Philippe Lavoie wrote:

> I think ".svn" is one of those cases where having two
> implementations is ok. Let me know how you guys feel about
> this.

This discussion has been raised a while ago as you already noticed. At
that time I had the impression, that some developers were not really
willing to make subversion do something differently on windows than on
unix just to deal with the quirkyness of some windows applications.
(IIS, ASP.Net, ...)

I think what subversion really wants/needs is a hidden/system folder
that contains metadata for the working copy.

- On unix this is easily achieved by prefixing the foldername with a '.'
hence .svn.
- On Windows, the same can be achieved by setting the hidden attribute.

The real reason is, that unix doesn't have a proper hidden attribute and
using '.' is a workaround for a missing os feature on unix.

That some Windows application do not like .svn as a foldername is also
something not-good(tm)

I'd suggest, that SVN_WC_ADM_DIR_NAME = "svn" on every OS, but upon
creation/access of SVN_WC_ADM_DIR_NAME, this is passed through a
routine, which handles the os specific stuff like
- prepending a '.' on *nixes,
- not prepending anything or '_' on *dows
- setting the hidden attribute on *dows upon creation
- and so on.

I think that projects like Subversion cannot afford a zero tolerance
policy towards bugs on other OS's.

If Mode A doesn't work on one OS and Mode B doesn't work on a different
OS there have to be two Modes for different OSs.

Just my 0.02$

Cheers
-Lübbe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 9 17:01:19 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.