[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: <kvistgaard_at_users.sourceforge.net>
Date: 2003-12-11 17:58:31 CET

Hi,

I agree that fixing the ASP.NET issue is important, I just think that
changing the '.svn' directory on windows is not the right solution. In
no particular order, my WC related use cases that will be affected by
such a change:

- Sharing WC between cygwin and native windows client, e.g. mixed use
of command line, subclipse and TortoiseSVN. I don't recall having
problems with 'eol-style:native' when setting 'Default Text File Type'
to 'DOS' in cygwin.
- Sharing working copies with large binary files, e.g. between
programmer (Linux) and artist (Windows)
- Scripts that involve the '.svn' directories are portable, e.g. build
scripts
- IDE configs are portable, e.g. excluding '.svn' folders

A solution that makes the admin directory configurable (even
defaulting to something else than '.svn') will be OK. Seems like a
prime candidate for 1.1 :-)

Hopefully this makes sense to someone besides myself.

Regards

Morten

Kevin Pilch-Bisson wrote:

> Considering the fact that portable working copies are already broken by
> eol-sytle:native files, I personally think we should change the name of .svn
> on windows, and be done with it.
>
> If someone cares about moving working copies, they can create a conversion
> script to do it. The only thing I can think of that this really breaks is a
> working copy that is shared between a unix and a windows machine via SMB or
> NFS. (which would already be in bad shape for eol-style:native).
>
> --
> ~~~~~~~~~~~~~~~~~~~~
> Kevin Pilch-Bisson
> ~~~~~~~~~~~~~~~~~~~~
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 11 17:59:25 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.