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

Re: Default eol styles

From: Casper Hornstrup <chorns_at_users.sourceforge.net>
Date: 2004-01-11 00:12:13 CET

> -----Oprindelig meddelelse-----
> Fra: Martin Furter [mailto:mf@rola.ch]
> Sendt: 10. januar 2004 22:31
> Til: Casper Hornstrup
> Cc: 'Erik Huelsmann'; dev@subversion.tigris.org;
> users@subversion.tigris.org
> Emne: Re: Default eol styles
>
> If you want to use auto-props don't forget to enable them:
> [miscellany] enable-auto-props = yes

That is nice to know.

> > 1) Its a per user configuration. Every user must configure these
> > rules and it is easy to forget this. If the rules change, then
> > all users have to change their configuration. Do they remember
> > this and will they do it when asked so there will be no problems
> > caused by forgetting this when they commit later? What if a user
> > missed the information on the change of rules?
> You can store the subversion config in a subversion
> repository (i think that's th reason why it is ~/.subversion
> on UNIX and not ~/.svn).

That would work if you already had a working copy, but as you point out
below, the user needs to take special care to load the configuration.
Manual labor, that I as a user, don't like to do. I want Subversion to
remember it for me or I forget and I'll have something similar to the
binary issue we have with CVS. A binary file that should have been added
in binary mode gets added in text mode because I forget to specify -kb
to cvs. I won't find out right away because cvs doesn't tell me that I
should add it in binary mode and it works fine with my configuration. I
will however find out when I've wasted X minutes of other developers
time because I broke the build. They are nice enough to tell me that I
screwed up (in the nicest way of course ;-).

I'm also pretty sure that the configuration file is not intended to be
put in the repository. It seems that it can contain absolute paths to
executables. It also contains editor preferences.

>
> > 2) Its an all or nothing approach. You can't make exceptions to the
> > rule so all projects you work on, on a particular computer, will
> > use the same rules. If you work on two projects that have a
> > conflict in the rules you either need to use two user accounts,
> > manually change the configuration file, or remember the rules and
> > apply them manually. I'd much rather have Subversion remember and
> > apply the rules I've setup for me.
> No, the config directory can be specified with --config-dir
> for the commandline client. But ofcourse you'd have to
> remember always specifying the right config. I don't know if
> other clients support that feature too.

I know TortoiseSVN doesn't.

>
> > 3) Its not safe. When the rules are on the client computer they can
> > get lost by a format and/or reinstall. When the rules are in the
> > repository, they don't get lost.
> Yeah, but other information then also gets lost, f.ex. the
> network configuration (yeah, i know that DHCP partially
> solves this) or configuration of other apps. I propose the
> same solution as for 1).

Yes. Someone should figure out how to put that configuration under
Version control ;-)

>
> Ofcourse i also would like to have this configuration stored
> in the repository and used only for that repos.
>
> Martin

Casper

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 11 00:16:14 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.