[Subversion] Subversion repository is now enforcing mime-types and eol-styles
Subversion handles end-of-line translation a bit differently from CVS. In Subversion, individual files need to be marked with both a mime-type and, for text files, an eol-style. These attributes determine how the Subversion client does end-of-line translation when communicating with the server. To maintain these properties requires some initial configuration of your Subversion client, described here under the "MIME types..." section: http://svn.boost.org/trac/boost/wiki/BoostSubversion The Subversion repository will verify that you have set the mime-type and eol-style properly when you try to commit, and will reject any commits that contain files without an appropriate MIME type. The configuration information above will automate the process of adding mime-types and eol-styles to new files, so the handling of end-of-line translation should be transparent in most cases. For more information about Subversion properties and how they are used with end-of-line translation, see: http://svnbook.red-bean.com/en/1.1/ch07s02.html - Doug
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Douglas Gregor Sent: 26 July 2007 14:50 To: boost@lists.boost.org Subject: [boost] [Subversion] Subversion repository is now enforcing mime-types and eol-styles
Subversion handles end-of-line translation a bit differently from CVS. In Subversion, individual files need to be marked with both a mime-type and, for text files, an eol-style. These attributes determine how the Subversion client does end-of-line translation when communicating with the server. To maintain these properties requires some initial configuration of your Subversion client, described here under the "MIME types..." section:
Aaaargh! I've tried to carry out the instructions and edited config as suggested. But, perhaps coincidentally?, I have now started to get (unwanted) commit notifications as attached, sent to the wrong list. Please can anyone suggest how to stop this. Thanks Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
On Jul 26, 2007, at 12:39 PM, Paul A Bristow wrote:
Aaaargh!
I've tried to carry out the instructions and edited config as suggested.
But, perhaps coincidentally?, I have now started to get (unwanted) commit notifications as attached, sent to the wrong list.
It was a coincidence. At around the same time, we put in a fix that gives the Trac notifications proper e-mail addresses, which had the side effect that you saw.
Please can anyone suggest how to stop this.
It should be fixed now. - Doug
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Doug Gregor Sent: 26 July 2007 18:59 To: boost@lists.boost.org Subject: Re: [boost] [Subversion] Subversion repository is now enforcingmime-types and eol-styles
On Jul 26, 2007, at 12:39 PM, Paul A Bristow wrote:
Aaaargh!
I've tried to carry out the instructions and edited config as suggested.
But, perhaps coincidentally?, I have now started to get (unwanted) commit notifications as attached, sent to the wrong list.
It was a coincidence. At around the same time, we put in a fix that gives the Trac notifications proper e-mail addresses, which had the side effect that you saw.
Please can anyone suggest how to stop this.
It should be fixed now.
What a relief - in final preparations for the massive math toolkit, I was about to make lots of commits and was worried about spamming everyone with messages like that. Thanks for all you work on moving to SVN - seems to work very nicely. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Douglas Gregor wrote:
Oh, how nice it would be if the server could set all these properties at check in time. No need to have users set this stuff up, and only one place to update it. Alas, I could not find a readily available solution :-( -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On Jul 26, 2007, at 8:35 PM, Rene Rivera wrote:
Douglas Gregor wrote:
Oh, how nice it would be if the server could set all these properties at check in time. No need to have users set this stuff up, and only one place to update it. Alas, I could not find a readily available solution :-(
That would be nice, yes, but there is no such option. - Doug
Douglas Gregor wrote:
On Jul 26, 2007, at 8:35 PM, Rene Rivera wrote:
http://svn.boost.org/trac/boost/wiki/BoostSubversion Oh, how nice it would be if the server could set all these
Douglas Gregor wrote: properties at check in time. No need to have users set this stuff up, and only one place to update it. Alas, I could not find a readily available solution :-(
That would be nice, yes, but there is no such option.
Alas, only an oft repeated request in their bug tracker: http://subversion.tigris.org/issues/show_bug.cgi?id=1974 Unfortunately, no appears to be working on this at the moment (that I know of).
Douglas Gregor wrote:
The auto-props for *.bat, *.cgi, *.cmd include svn-mime-type. That should read as svn:mime-type, I guess. Regeards, Sebastian
On Sat, 2007-07-28 at 11:05 +0200, Sebastian Ramacher wrote:
Douglas Gregor wrote:
The auto-props for *.bat, *.cgi, *.cmd include svn-mime-type. That should read as svn:mime-type, I guess.
Thanks! Fixed. - Doug
Douglas Gregor wrote:
The section starts with: Internally, Subversion stores all text files using the Unix line endings (i.e., a single line feed). This is factually wrong. By default, Subversion does not care about line endings at all (because it uses binary deltas, not text deltas as CVS used to). It only starts to use Unix line endings when you use svn:eof-style.
The Subversion repository will verify that you have set the mime-type and eol-style properly
What does it mean for mime-type to be "property set"? Subversion only cares if the mime type is "text/*" or not, and otherwise mime type is irrelevant. So, what exactly is enforced? - Volodya
On Jul 28, 2007, at 10:28 AM, Vladimir Prus wrote:
Douglas Gregor wrote:
The section starts with:
Internally, Subversion stores all text files using the Unix line endings (i.e., a single line feed).
This is factually wrong. By default, Subversion does not care about line endings at all (because it uses binary deltas, not text deltas as CVS used to). It only starts to use Unix line endings when you use svn:eof-style.
You're right; I've rewritten that text.
The Subversion repository will verify that you have set the mime-type and eol-style properly
What does it mean for mime-type to be "property set"? Subversion only cares if the mime type is "text/*" or not, and otherwise mime type is irrelevant.
So, what exactly is enforced?
I've rewritten that part, too. All files committed need to have `svn:mime-type` set; if that MIME type is text/something, then the file must have svn:eol-style set. - Doug
on Mon Jul 30 2007, Doug Gregor <dgregor-AT-osl.iu.edu> wrote:
The Subversion repository will verify that you have set the mime-type and eol-style properly
What does it mean for mime-type to be "property set"? Subversion only cares if the mime type is "text/*" or not, and otherwise mime type is irrelevant.
So, what exactly is enforced?
I've rewritten that part, too.
All files committed need to have `svn:mime-type` set; if that MIME type is text/something, then the file must have svn:eol-style set.
Are you sure this is going to be worth the trouble? Almost every tool out there is EOL-style-agnostic, which means that most of our source files will work properly when treated as binary. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
On Jul 31, 2007, at 11:08 AM, David Abrahams wrote:
Are you sure this is going to be worth the trouble? Almost every tool out there is EOL-style-agnostic, which means that most of our source files will work properly when treated as binary.
Yes, this is worth the trouble. - Doug
participants (9)
-
David Abrahams -
Doug Gregor -
Douglas Gregor
-
Douglas Gregor -
eg -
Paul A Bristow -
Rene Rivera -
Sebastian Ramacher -
Vladimir Prus