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

Re: cr, lf on merge ... implement or use gnu diff option?

From: solo turn <soloturn99_at_yahoo.com>
Date: 2002-11-16 13:59:53 CET

you want to say you lost a binary file once every two years to cvs
you set a default to prevent this?

even if you store 95% text files, even if you know that different
plattforms with different character sets exist? try to run svn client
on z/os unix system service (ebcdic encoding). good design means
"text files have to be converted to local character set". and of
course this includes line endings.

deciding whether a file is text or binary is a different question.
and i consider svn in this respect far more advanced than cvs.

"don't mangle unless told so" sounds like the early emacs versions,
when you trie to exit and not save a modified file:
- are you sure you want to exit (default no) - do you want to save
your file (default yes) - you have modified buffers, are you really
sure you want to exit (default no)

and it needed a bill gates or steve jobs or jean louis gasse to
proove that dummy users are able to handle situations like this one
with one question, and experts can turn the question of.

*giggle*

(and don't get me wrong: i can perfectly live with how it is now,
cause there is workarounds. but at the long run i don't think the svn
guide should be a guide to scripts and workarounds. it should be as
short as possible).

--- Peter Davis <peter@pdavis.cx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 13 November 2002 16:53, solo turn wrote:
> > is there a chance that subversion will just ommit this by turning
> it
> > around and use a property for the rare case (makefiles)?
>
> The reason it is not the default is because mangling the line
> endings can
> destroy data. If you've never lost a binary file to CVS or any
> other
> line-ending-mangling program, then consider yourself lucky.
> Subversion's
> philosophy is to not change *any* data you send to it unless you
> explicitely
> tell it to do so. So no, there is probably no chance that this
> will become
> the default.
>
>
> What probably will change, though, is the concept of default
> properties.
> There have already been discussions of how to implement it,
> although it
> probably won't happen until after a 1.0 release.
>
> You will be able to set some configuration (either in a client- or
> repository-configuration file, or as a versioned property of a
> directory)
> that will specify filename patterns and the default properties to
> be set for
> matching files. You will be able to set a pattern that matches
> "Makefile" or
> "*.{c,h,txt}" so that svn:eol-style (and even svn:mime-type or any
> other
> property) will be set automatically. You'll have to set up these
> default
> property settings yourself, so that the "don't mangle unless told
> to do so"
> philosophy is not violated.0
>
>
> At least, that's my understanding. I think it's a good idea, and
> it sounds
> like it would solve your problem. In the meantime, you just have
> to write a
> script to set svn:eol-style to 'native' on your files.
>
> - --
> Peter Davis
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
>
> iD8DBQE90vgHhDAgUT1yirARAnj9AJ9CFbO+fvUable4dW/PGH8qFnZm5wCfWzIb
> l1CEtgbfjDQavcf6xH6WEeE=
> =UtER
> -----END PGP SIGNATURE-----
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 16 14:00:38 2002

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.