You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Daniel Kulp <da...@iona.com> on 2006/11/09 16:57:41 UTC

svn properties....

I noticed that a lot of files in qpid don't have any svn properties set on 
them so they end up with mixed cr/lf issues, wrong mime types when 
browsing, etc....   That's probably not a good thing. 

I've attached a little bash shell script that I use to fix up issues like 
that in a bunch of SVN repositories.   It runs on Linux (maybe on Mac as 
well, GNU xargs required) and will reset all the properties for the types 
I've been exposed to.   Someone should propable run it on trunk to get 
things into a good consistent state and then start from there.

QPID should also define a definite set of auto props that developers 
should be using.   A good starting point may be the CXF ones at:
http://svn.apache.org/repos/asf/incubator/cxf/trunk/etc/svn-auto-props
they should cover MOST of the stuff encountered.   Not sure about the 
ruby/python stuff.


-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194   F:781-902-8001
daniel.kulp@iona.com

Re: svn properties....

Posted by Gordon Sim <gs...@redhat.com>.
Steve Vinoski wrote:
> Unless someone objects, I'll run this script today in the Java tree and 
> commit it. I'd rather leave the C++ tree to Alan or Gordon and the Ruby 
> and Python trees to Rafi, unless you guys want me to take care of those 
> trees too, just let me know.

Done on cpp tree.

Re: svn properties....

Posted by Daniel Kulp <da...@iona.com>.
Steve,

The current "proper" apache license header doesn't have the copyright date 
line it.   I noticed you stuck that in the script.

Dan


On Thursday November 09 2006 5:21 pm, Steve Vinoski wrote:
> On Nov 9, 2006, at 11:44 AM, Carl Trieloff wrote:
> > Might as well run it on all trees if you are going to go to the
> > effort. Also, Dan do you
> > mind if we check the script into a tools dir somewhere in our svn?
> > I am sure this is some
> > that will come up again.
>
> I created bin and etc directories under trunk/qpid, put Dan's script
> in bin, and put the svn-auto-props file in etc.
>
> --steve
>
> > Carl.
> >
> > Steve Vinoski wrote:
> >> On Nov 9, 2006, at 10:57 AM, Daniel Kulp wrote:
> >>> I noticed that a lot of files in qpid don't have any svn
> >>> properties set on
> >>> them so they end up with mixed cr/lf issues, wrong mime types when
> >>> browsing, etc....   That's probably not a good thing.
> >>
> >> Dan, good catch. I was about to send a similar note, as last night
> >> I found a bunch of source files containing Windows line endings.
> >>
> >>> I've attached a little bash shell script that I use to fix up
> >>> issues like
> >>> that in a bunch of SVN repositories.   It runs on Linux (maybe on
> >>> Mac as
> >>> well, GNU xargs required) and will reset all the properties for
> >>> the types
> >>> I've been exposed to.   Someone should propable run it on trunk
> >>> to get
> >>> things into a good consistent state and then start from there.
> >>
> >> Unless someone objects, I'll run this script today in the Java
> >> tree and commit it. I'd rather leave the C++ tree to Alan or
> >> Gordon and the Ruby and Python trees to Rafi, unless you guys want
> >> me to take care of those trees too, just let me know.
> >>
> >>> QPID should also define a definite set of auto props that
> >>> developers should be using.   A good starting point may be the CXF
> >>> ones at:
> >>> http://svn.apache.org/repos/asf/incubator/cxf/trunk/etc/svn-auto-
> >>> props
> >>> they should cover MOST of the stuff encountered.   Not sure about
> >>> the
> >>> ruby/python stuff.
> >>
> >> I've been using the CXF auto props and they work well. I'll commit
> >> a copy of them into the Qpid tree today.
> >>
> >> Thanks Dan!
> >>
> >> --steve
> >>
> >>> --J. Daniel Kulp
> >>> Principal Engineer
> >>> IONA
> >>> P: 781-902-8727    C: 508-380-7194   F:781-902-8001
> >>> daniel.kulp@iona.com
> >>> <set_svn_properties.sh>

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194   F:781-902-8001
daniel.kulp@iona.com

Re: svn properties....

Posted by John O'Hara <jo...@gmail.com>.
+1 to adding it.


On 12/11/06, Robert Greig <ro...@gmail.com> wrote:
>
> On 10/11/06, Martin Ritchie <ri...@apache.org> wrote:
> > Can we all then please set our svn clients to use the auto-props.
>
> We have had this problem with each svn repository the codebase has
> lived in and the problem with a solution that relies upon everyone
> configuring their clients is that:
>
> 1) new people don't necessarily know
> 2) sometimes people switch clients or machines or whatever and by
> accident don't set their clients up correctly.
> 3) sometimes new extensions come along and we all have to remember to
> update our auto-props
>
> The solution we came up with was to have a pre-commit hook that checks
> that every text file has the svn:eol-style property set. If it detects
> that someone is trying to commit a text file without that property
> set, the commit is aborted with an appropriate message.
>
> I have attached the commit hook - what would people think about
> getting that added to our svn repository?
>
> RG
>
>
>

Re: svn properties....

Posted by Robert Greig <ro...@gmail.com>.
On 13/11/06, Carl Trieloff <cc...@redhat.com> wrote:
>
> do you want to write a mail to infra and cc us. Alternately if you
> irc.freenode.net and go to #asfinfra there is usually someone
> that can help on-line.

Yes, I'll follow up with the infrastructure people via email.

RG

Re: svn properties....

Posted by Carl Trieloff <cc...@redhat.com>.
Robert,

do you want to write a mail to infra and cc us. Alternately if you 
irc.freenode.net and go to #asfinfra there is usually someone
that can help on-line.

Carl.

Robert Greig wrote:
> On 13/11/06, Daniel Kulp <da...@iona.com> wrote:
>> On Monday November 13 2006 10:46 am, Alan Conway wrote:
>> > Is it possible to get triggers to actually fix the properties rather
>> > than just abort the commit and tell you to fix them?
>>
>> I don't think so.   I don't think you can modify the transaction.
>
> Yes, that is correct. All you can do is abort the tran.
>
> It would be nice IMO if you could apply auto-props at the repo though.
>
> RG


Re: svn properties....

Posted by Robert Greig <ro...@gmail.com>.
On 13/11/06, Daniel Kulp <da...@iona.com> wrote:
> On Monday November 13 2006 10:46 am, Alan Conway wrote:
> > Is it possible to get triggers to actually fix the properties rather
> > than just abort the commit and tell you to fix them?
>
> I don't think so.   I don't think you can modify the transaction.

Yes, that is correct. All you can do is abort the tran.

It would be nice IMO if you could apply auto-props at the repo though.

RG

Re: svn properties....

Posted by Daniel Kulp <da...@iona.com>.
On Monday November 13 2006 10:46 am, Alan Conway wrote:
> Is it possible to get triggers to actually fix the properties rather
> than just abort the commit and tell you to fix them?

I don't think so.   I don't think you can modify the transaction.

In anycase, I'd still prefer the "abort and have you fix it" approach for 
now.   Getting people to fix their SVN clients to me is important.   When 
they commit to other projects (internal to their company, other apache 
projects, codehaus projects, etc....), they cannot rely on a script to 
fix/work around their setup problems.   We need to tell them to get it 
fixed and force them to do so.

Dan


>
> On Mon, 2006-11-13 at 10:25 -0500, Daniel Kulp wrote:
> > On Monday November 13 2006 10:14 am, Robert Greig wrote:
> > > On 13/11/06, Steve Vinoski <vi...@iona.com> wrote:
> > > > I don't object at all to adding it, but seeing as how we're part
> > > > of a much larger repository, could we even make such a change
> > > > without getting buy-in across all the other projects sharing this
> > > > repository?
> > >
> > > Yes that could be a problem. What we could do is put in a test at
> > > the stop to do if the path of the commit starts with "qpid" so it
> > > only really applies to our project. Or read a file to check which
> > > commit paths to match on, since that would make it easy to roll out
> > > to other projects.
> >
> > Before spending much time on it, you probably should send a note to
> > infrastructure@apache.org asking if it's possible and how to proceed.
> >
> > Adding hooks into SVN, even if it bails if it's not qpid, would
> > affect ALL commits as processes would need to be forked to do the
> > validation and such.   Infrastructure would need to be involved to
> > make sure that's acceptable.
> >
> > That all said, I'd love it.   It would be great if it could be
> > updated to handle all the auto_props, but even flagging the eol-style
> > is a huge help.

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194   F:781-902-8001
daniel.kulp@iona.com

Re: svn properties....

Posted by Steve Vinoski <vi...@iona.com>.
On Nov 13, 2006, at 10:46 AM, Alan Conway wrote:

> Is it possible to get triggers to actually fix the properties rather
> than just abort the commit and tell you to fix them?

Doesn't look that way -- the SVN book says the following.
"Warning

Do not attempt to modify the transaction using hook scripts. A common  
example of this would be to automatically set properties such as  
svn:eol-style or svn:mime-type during the commit. While this might  
seem like a good idea, it causes problems. The main problem is that  
the client does not know about the change made by the hook script,  
and there is no way to inform the client that it is out-of-date. This  
inconsistency can lead to surprising and unexpected behavior.

Instead of attempting to modify the transaction, it is much better to  
check the transaction in the pre-commit hook and reject the commit if  
it does not meet the desired requirements."

--steve

>
> On Mon, 2006-11-13 at 10:25 -0500, Daniel Kulp wrote:
>> On Monday November 13 2006 10:14 am, Robert Greig wrote:
>>> On 13/11/06, Steve Vinoski <vi...@iona.com> wrote:
>>>> I don't object at all to adding it, but seeing as how we're part  
>>>> of a
>>>> much larger repository, could we even make such a change without
>>>> getting buy-in across all the other projects sharing this  
>>>> repository?
>>>
>>> Yes that could be a problem. What we could do is put in a test at  
>>> the
>>> stop to do if the path of the commit starts with "qpid" so it only
>>> really applies to our project. Or read a file to check which commit
>>> paths to match on, since that would make it easy to roll out to  
>>> other
>>> projects.
>>
>> Before spending much time on it, you probably should send a note to
>> infrastructure@apache.org asking if it's possible and how to proceed.
>>
>> Adding hooks into SVN, even if it bails if it's not qpid, would  
>> affect ALL
>> commits as processes would need to be forked to do the validation and
>> such.   Infrastructure would need to be involved to make sure that's
>> acceptable.
>>
>> That all said, I'd love it.   It would be great if it could be  
>> updated to
>> handle all the auto_props, but even flagging the eol-style is a huge
>> help.
>>
>


Re: svn properties....

Posted by Alan Conway <ac...@redhat.com>.
Is it possible to get triggers to actually fix the properties rather
than just abort the commit and tell you to fix them?

On Mon, 2006-11-13 at 10:25 -0500, Daniel Kulp wrote:
> On Monday November 13 2006 10:14 am, Robert Greig wrote:
> > On 13/11/06, Steve Vinoski <vi...@iona.com> wrote:
> > > I don't object at all to adding it, but seeing as how we're part of a
> > > much larger repository, could we even make such a change without
> > > getting buy-in across all the other projects sharing this repository?
> >
> > Yes that could be a problem. What we could do is put in a test at the
> > stop to do if the path of the commit starts with "qpid" so it only
> > really applies to our project. Or read a file to check which commit
> > paths to match on, since that would make it easy to roll out to other
> > projects.
> 
> Before spending much time on it, you probably should send a note to 
> infrastructure@apache.org asking if it's possible and how to proceed. 
> 
> Adding hooks into SVN, even if it bails if it's not qpid, would affect ALL 
> commits as processes would need to be forked to do the validation and 
> such.   Infrastructure would need to be involved to make sure that's 
> acceptable. 
> 
> That all said, I'd love it.   It would be great if it could be updated to 
> handle all the auto_props, but even flagging the eol-style is a huge 
> help.
> 


Re: svn properties....

Posted by Daniel Kulp <da...@iona.com>.
On Monday November 13 2006 10:14 am, Robert Greig wrote:
> On 13/11/06, Steve Vinoski <vi...@iona.com> wrote:
> > I don't object at all to adding it, but seeing as how we're part of a
> > much larger repository, could we even make such a change without
> > getting buy-in across all the other projects sharing this repository?
>
> Yes that could be a problem. What we could do is put in a test at the
> stop to do if the path of the commit starts with "qpid" so it only
> really applies to our project. Or read a file to check which commit
> paths to match on, since that would make it easy to roll out to other
> projects.

Before spending much time on it, you probably should send a note to 
infrastructure@apache.org asking if it's possible and how to proceed. 

Adding hooks into SVN, even if it bails if it's not qpid, would affect ALL 
commits as processes would need to be forked to do the validation and 
such.   Infrastructure would need to be involved to make sure that's 
acceptable. 

That all said, I'd love it.   It would be great if it could be updated to 
handle all the auto_props, but even flagging the eol-style is a huge 
help.

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194   F:781-902-8001
daniel.kulp@iona.com

Re: svn properties....

Posted by Robert Greig <ro...@gmail.com>.
On 13/11/06, Steve Vinoski <vi...@iona.com> wrote:

> I don't object at all to adding it, but seeing as how we're part of a
> much larger repository, could we even make such a change without
> getting buy-in across all the other projects sharing this repository?

Yes that could be a problem. What we could do is put in a test at the
stop to do if the path of the commit starts with "qpid" so it only
really applies to our project. Or read a file to check which commit
paths to match on, since that would make it easy to roll out to other
projects.

RG

Re: svn properties....

Posted by Steve Vinoski <vi...@iona.com>.
I don't object at all to adding it, but seeing as how we're part of a  
much larger repository, could we even make such a change without  
getting buy-in across all the other projects sharing this repository?

--steve

On Nov 13, 2006, at 9:56 AM, Carl Trieloff wrote:

>
> +1 to adding it.
>
> Carl.
>
> Robert Greig wrote:
>> On 10/11/06, Martin Ritchie <ri...@apache.org> wrote:
>>> Can we all then please set our svn clients to use the auto-props.
>>
>> We have had this problem with each svn repository the codebase has
>> lived in and the problem with a solution that relies upon everyone
>> configuring their clients is that:
>>
>> 1) new people don't necessarily know
>> 2) sometimes people switch clients or machines or whatever and by
>> accident don't set their clients up correctly.
>> 3) sometimes new extensions come along and we all have to remember to
>> update our auto-props
>>
>> The solution we came up with was to have a pre-commit hook that  
>> checks
>> that every text file has the svn:eol-style property set. If it  
>> detects
>> that someone is trying to commit a text file without that property
>> set, the commit is aborted with an appropriate message.
>>
>> I have attached the commit hook - what would people think about
>> getting that added to our svn repository?
>>
>> RG
>> --------------------------------------------------------------------- 
>> ---
>>
>> #!/usr/bin/env perl
>> #
>> # svn-check-eol-style.pl: commit hook-script to check that added text
>> # files have a svn:eol-style property set.  We assume anything  
>> with # a text/* mime type or without a mime type is text (since  
>> svn auto-sets
>> # a binary mime type on files it detects as binary).
>> # # Usage: svn-check-eol-style.pl REPOS TXN-NAME
>> #
>> # Written by Ewen McNeill <ew...@imatix.com>, 2005/08/08
>> #
>> # Based heavily on: # http://svn.collab.net/repos/svn/trunk/ 
>> contrib/hook-scripts/check-mime-type.pl
>> #
>> # as documented below
>> #
>> #  
>> ====================================================================
>> # commit-mime-type-check.pl: check that every added file has the
>> # svn:mime-type property set and every added file with a mime-type
>> # matching text/* also has svn:eol-style set. If any file fails this
>> # test the user is sent a verbose error message suggesting  
>> solutions and
>> # the commit is aborted.
>> #
>> # Usage: commit-mime-type-check.pl REPOS TXN-NAME
>> #  
>> ====================================================================
>> # Most of commit-mime-type-check.pl was taken from
>> # commit-access-control.pl, Revision 9986, 2004-06-14 16:29:22 -0400.
>> #  
>> ====================================================================
>> # Copyright (c) 2000-2004 CollabNet.  All rights reserved.
>> #
>> # This software is licensed as described in the file COPYING, which
>> # you should have received as part of this distribution.  The terms
>> # are also available at http://subversion.tigris.org/license.html.
>> # If newer versions of this license are posted there, you may use a
>> # newer version instead, at your option.
>> #
>> # This software consists of voluntary contributions made by many
>> # individuals.  For exact contribution history, see the revision
>> # history and logs, available at http://subversion.tigris.org/.
>> #  
>> ====================================================================
>>
>> # Turn on warnings the best way depending on the Perl version.
>> BEGIN {
>>   if ( $] >= 5.006_000)
>>     { require warnings; import warnings; }                         
>> else      { $^W = 1; }               }
>> use strict;
>> use Carp;
>>
>>
>> ##################################################################### 
>> #
>> # Configuration section.
>>
>> # Svnlook path.
>> my $svnlook = "/usr/bin/svnlook";
>>
>> # Since the path to svnlook depends upon the local installation
>> # preferences, check that the required program exists to insure that
>> # the administrator has set up the script properly.
>> {
>>   my $ok = 1;
>>   foreach my $program ($svnlook)
>>     {
>>       if (-e $program)
>>         {
>>           unless (-x $program)
>>             {
>>               warn "$0: required program `$program' is not  
>> executable, ",
>>                    "edit $0.\n";
>>               $ok = 0;
>>             }
>>         }
>>       else
>>         {
>>           warn "$0: required program `$program' does not exist,  
>> edit $0.\n";
>>           $ok = 0;
>>         }
>>     }
>>   exit 1 unless $ok;
>> }
>>
>> ##################################################################### 
>> #
>> # Initial setup/command-line handling.
>>
>> &usage unless @ARGV == 2;
>>
>> my $repos        = shift;
>> my $txn          = shift;
>>
>> unless (-e $repos)
>>   {
>>     &usage("$0: repository directory `$repos' does not exist.");
>>   }
>> unless (-d $repos)
>>   {
>>     &usage("$0: repository directory `$repos' is not a directory.");
>>   }
>>
>> # Define two constant subroutines to stand for read-only or read- 
>> write
>> # access to the repository.
>> sub ACCESS_READ_ONLY  () { 'read-only' }
>> sub ACCESS_READ_WRITE () { 'read-write' }
>>
>>
>> ##################################################################### 
>> #
>> # Harvest data using svnlook.
>>
>> # Change into /tmp so that svnlook diff can create its .svnlook
>> # directory.
>> # # XXX: security - race
>> my $tmp_dir = '/tmp';
>> chdir($tmp_dir)
>>   or die "$0: cannot chdir `$tmp_dir': $!\n";
>>
>> # Figure out what files have added using svnlook.
>> my @files_added;
>> foreach my $line (&read_from_process($svnlook, 'changed', $repos,  
>> '-t', $txn))
>>   {
>> 		# Add only files that were added to @files_added
>>     if ($line =~ /^A.  (.*[^\/])$/)
>>       {
>>         push(@files_added, $1);
>>       }
>>   }
>>
>> my @errors;
>> foreach my $path ( @files_added ) 	{
>> 		my $mime_type;
>> 		my $eol_style;
>>
>> 		# Parse the complete list of property values of the file $path  
>> to extract
>> 		# the mime-type and eol-style
>> 		foreach my $prop (&read_from_process($svnlook, 'proplist',  
>> $repos, '-t', 		                  $txn, '--verbose', $path))
>> 			{
>> 				if ($prop =~ /^\s*svn:mime-type : (\S+)/)
>> 					{
>> 						$mime_type = $1;
>> 					}
>> 				elsif ($prop =~ /^\s*svn:eol-style : (\S+)/)
>> 					{
>> 						$eol_style = $1;
>> 					}
>> 			}
>>
>> 		# Detect error conditions and add them to @errors
>> #		if (not $mime_type)
>> #			{
>> #				push @errors, "$path : svn:mime-type is not set";
>> #			}
>> #		elsif ($mime_type =~ /^text\// and not $eol_style)
>> 		if ((not $mime_type or $mime_type =~ /^text\//) and 		    not  
>> $eol_style)
>> 			{
>> 				$mime_type='' unless defined($mime_type);
>> 				push @errors, "$path:\n    svn:eol-style is not set and  
>> svn:mime-type is not a binary type";
>> 			}
>> 	}
>>
>> # If there are any errors list the problem files and give information
>> # on how to avoid the problem. Hopefully people will set up auto- 
>> props
>> # and will not see this verbose message more than once.
>> if (@errors)
>>   {
>> #   warn "$0:\n\n",
>>     warn "SVN Hook: Check eol-style:\n\n",
>>          join("\n", @errors), "\n\n",
>> 				 <<EOS;
>>
>>     Every added text file must have the svn:eol-style set.  Either  
>> upgrade
>>     to a version of subversion which does this automatically,  
>> configure
>>     the file extension in the auto-props section of your  
>> ~/.subversion/config
>>     or run:
>>         svn propset svn:eol-style native path/of/file
>>         Read the Subversion book (http://svnbook.red-bean.com/),  
>> Chapter 7,     Properties section, Automatic Property Setting  
>> subsection for more help.
>> EOS
>>     exit 1;
>>   }
>> else
>>   {
>>     exit 0;
>>   }
>>
>> sub usage
>> {
>>   warn "@_\n" if @_;
>>   die "usage: $0 REPOS TXN-NAME\n";
>> }
>>
>> sub safe_read_from_pipe
>> {
>>   unless (@_)
>>     {
>>       croak "$0: safe_read_from_pipe passed no arguments.\n";
>>     }
>>   print "Running @_\n";
>>   my $pid = open(SAFE_READ, '-|');
>>   unless (defined $pid)
>>     {
>>       die "$0: cannot fork: $!\n";
>>     }
>>   unless ($pid)
>>     {
>>       open(STDERR, ">&STDOUT")
>>         or die "$0: cannot dup STDOUT: $!\n";
>>       exec(@_)
>>         or die "$0: cannot exec `@_': $!\n";
>>     }
>>   my @output;
>>   while (<SAFE_READ>)
>>     {
>>       chomp;
>>       push(@output, $_);
>>     }
>>   close(SAFE_READ);
>>   my $result = $?;
>>   my $exit   = $result >> 8;
>>   my $signal = $result & 127;
>>   my $cd     = $result & 128 ? "with core dump" : "";
>>   if ($signal or $cd)
>>     {
>>       warn "$0: pipe from `@_' failed $cd: exit=$exit signal= 
>> $signal\n";
>>     }
>>   if (wantarray)
>>     {
>>       return ($result, @output);
>>     }
>>   else
>>     {
>>       return $result;
>>     }
>> }
>>
>> sub read_from_process
>>   {
>>   unless (@_)
>>     {
>>       croak "$0: read_from_process passed no arguments.\n";
>>     }
>>   my ($status, @output) = &safe_read_from_pipe(@_);
>>   if ($status)
>>     {
>>       if (@output)
>>         {
>>           die "$0: `@_' failed with this output:\n", join("\n",  
>> @output), "\n";
>>         }
>>       else
>>         {
>>           die "$0: `@_' failed with no output.\n";
>>         }
>>     }
>>   else
>>     {
>>       return @output;
>>     }
>> }
>>
>


Re: svn properties....

Posted by Carl Trieloff <cc...@redhat.com>.
+1 to adding it.

Carl.

Robert Greig wrote:
> On 10/11/06, Martin Ritchie <ri...@apache.org> wrote:
>> Can we all then please set our svn clients to use the auto-props.
>
> We have had this problem with each svn repository the codebase has
> lived in and the problem with a solution that relies upon everyone
> configuring their clients is that:
>
> 1) new people don't necessarily know
> 2) sometimes people switch clients or machines or whatever and by
> accident don't set their clients up correctly.
> 3) sometimes new extensions come along and we all have to remember to
> update our auto-props
>
> The solution we came up with was to have a pre-commit hook that checks
> that every text file has the svn:eol-style property set. If it detects
> that someone is trying to commit a text file without that property
> set, the commit is aborted with an appropriate message.
>
> I have attached the commit hook - what would people think about
> getting that added to our svn repository?
>
> RG
> ------------------------------------------------------------------------
>
> #!/usr/bin/env perl
> #
> # svn-check-eol-style.pl: commit hook-script to check that added text
> # files have a svn:eol-style property set.  We assume anything with 
> # a text/* mime type or without a mime type is text (since svn auto-sets
> # a binary mime type on files it detects as binary).
> # 
> # Usage: svn-check-eol-style.pl REPOS TXN-NAME
> #
> # Written by Ewen McNeill <ew...@imatix.com>, 2005/08/08
> #
> # Based heavily on: 
> # http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/check-mime-type.pl
> #
> # as documented below
> #
> # ====================================================================
> # commit-mime-type-check.pl: check that every added file has the
> # svn:mime-type property set and every added file with a mime-type
> # matching text/* also has svn:eol-style set. If any file fails this
> # test the user is sent a verbose error message suggesting solutions and
> # the commit is aborted.
> #
> # Usage: commit-mime-type-check.pl REPOS TXN-NAME
> # ====================================================================
> # Most of commit-mime-type-check.pl was taken from
> # commit-access-control.pl, Revision 9986, 2004-06-14 16:29:22 -0400.
> # ====================================================================
> # Copyright (c) 2000-2004 CollabNet.  All rights reserved.
> #
> # This software is licensed as described in the file COPYING, which
> # you should have received as part of this distribution.  The terms
> # are also available at http://subversion.tigris.org/license.html.
> # If newer versions of this license are posted there, you may use a
> # newer version instead, at your option.
> #
> # This software consists of voluntary contributions made by many
> # individuals.  For exact contribution history, see the revision
> # history and logs, available at http://subversion.tigris.org/.
> # ====================================================================
>
> # Turn on warnings the best way depending on the Perl version.
> BEGIN {
>   if ( $] >= 5.006_000)
>     { require warnings; import warnings; }                      
>   else  
>     { $^W = 1; }               
> }           
>
> use strict;
> use Carp;
>
>
> ######################################################################
> # Configuration section.
>
> # Svnlook path.
> my $svnlook = "/usr/bin/svnlook";
>
> # Since the path to svnlook depends upon the local installation
> # preferences, check that the required program exists to insure that
> # the administrator has set up the script properly.
> {
>   my $ok = 1;
>   foreach my $program ($svnlook)
>     {
>       if (-e $program)
>         {
>           unless (-x $program)
>             {
>               warn "$0: required program `$program' is not executable, ",
>                    "edit $0.\n";
>               $ok = 0;
>             }
>         }
>       else
>         {
>           warn "$0: required program `$program' does not exist, edit $0.\n";
>           $ok = 0;
>         }
>     }
>   exit 1 unless $ok;
> }
>
> ######################################################################
> # Initial setup/command-line handling.
>
> &usage unless @ARGV == 2;
>
> my $repos        = shift;
> my $txn          = shift;
>
> unless (-e $repos)
>   {
>     &usage("$0: repository directory `$repos' does not exist.");
>   }
> unless (-d $repos)
>   {
>     &usage("$0: repository directory `$repos' is not a directory.");
>   }
>
> # Define two constant subroutines to stand for read-only or read-write
> # access to the repository.
> sub ACCESS_READ_ONLY  () { 'read-only' }
> sub ACCESS_READ_WRITE () { 'read-write' }
>
>
> ######################################################################
> # Harvest data using svnlook.
>
> # Change into /tmp so that svnlook diff can create its .svnlook
> # directory.
> # 
> # XXX: security - race
> my $tmp_dir = '/tmp';
> chdir($tmp_dir)
>   or die "$0: cannot chdir `$tmp_dir': $!\n";
>
> # Figure out what files have added using svnlook.
> my @files_added;
> foreach my $line (&read_from_process($svnlook, 'changed', $repos, '-t', $txn))
>   {
> 		# Add only files that were added to @files_added
>     if ($line =~ /^A.  (.*[^\/])$/)
>       {
>         push(@files_added, $1);
>       }
>   }
>
> my @errors;
> foreach my $path ( @files_added ) 
> 	{
> 		my $mime_type;
> 		my $eol_style;
>
> 		# Parse the complete list of property values of the file $path to extract
> 		# the mime-type and eol-style
> 		foreach my $prop (&read_from_process($svnlook, 'proplist', $repos, '-t', 
> 		                  $txn, '--verbose', $path))
> 			{
> 				if ($prop =~ /^\s*svn:mime-type : (\S+)/)
> 					{
> 						$mime_type = $1;
> 					}
> 				elsif ($prop =~ /^\s*svn:eol-style : (\S+)/)
> 					{
> 						$eol_style = $1;
> 					}
> 			}
>
> 		# Detect error conditions and add them to @errors
> #		if (not $mime_type)
> #			{
> #				push @errors, "$path : svn:mime-type is not set";
> #			}
> #		elsif ($mime_type =~ /^text\// and not $eol_style)
> 		if ((not $mime_type or $mime_type =~ /^text\//) and 
> 		    not $eol_style)
> 			{
> 				$mime_type='' unless defined($mime_type);
> 				push @errors, "$path:\n    svn:eol-style is not set and svn:mime-type is not a binary type";
> 			}
> 	}
>
> # If there are any errors list the problem files and give information
> # on how to avoid the problem. Hopefully people will set up auto-props
> # and will not see this verbose message more than once.
> if (@errors)
>   {
> #   warn "$0:\n\n",
>     warn "SVN Hook: Check eol-style:\n\n",
>          join("\n", @errors), "\n\n",
> 				 <<EOS;
>
>     Every added text file must have the svn:eol-style set.  Either upgrade
>     to a version of subversion which does this automatically, configure
>     the file extension in the auto-props section of your ~/.subversion/config
>     or run:
>     
>     svn propset svn:eol-style native path/of/file
>     
>     Read the Subversion book (http://svnbook.red-bean.com/), Chapter 7, 
>     Properties section, Automatic Property Setting subsection for more help.
> EOS
>     exit 1;
>   }
> else
>   {
>     exit 0;
>   }
>
> sub usage
> {
>   warn "@_\n" if @_;
>   die "usage: $0 REPOS TXN-NAME\n";
> }
>
> sub safe_read_from_pipe
> {
>   unless (@_)
>     {
>       croak "$0: safe_read_from_pipe passed no arguments.\n";
>     }
>   print "Running @_\n";
>   my $pid = open(SAFE_READ, '-|');
>   unless (defined $pid)
>     {
>       die "$0: cannot fork: $!\n";
>     }
>   unless ($pid)
>     {
>       open(STDERR, ">&STDOUT")
>         or die "$0: cannot dup STDOUT: $!\n";
>       exec(@_)
>         or die "$0: cannot exec `@_': $!\n";
>     }
>   my @output;
>   while (<SAFE_READ>)
>     {
>       chomp;
>       push(@output, $_);
>     }
>   close(SAFE_READ);
>   my $result = $?;
>   my $exit   = $result >> 8;
>   my $signal = $result & 127;
>   my $cd     = $result & 128 ? "with core dump" : "";
>   if ($signal or $cd)
>     {
>       warn "$0: pipe from `@_' failed $cd: exit=$exit signal=$signal\n";
>     }
>   if (wantarray)
>     {
>       return ($result, @output);
>     }
>   else
>     {
>       return $result;
>     }
> }
>
> sub read_from_process
>   {
>   unless (@_)
>     {
>       croak "$0: read_from_process passed no arguments.\n";
>     }
>   my ($status, @output) = &safe_read_from_pipe(@_);
>   if ($status)
>     {
>       if (@output)
>         {
>           die "$0: `@_' failed with this output:\n", join("\n", @output), "\n";
>         }
>       else
>         {
>           die "$0: `@_' failed with no output.\n";
>         }
>     }
>   else
>     {
>       return @output;
>     }
> }
>   


Re: svn properties....

Posted by Robert Greig <ro...@gmail.com>.
On 10/11/06, Martin Ritchie <ri...@apache.org> wrote:
> Can we all then please set our svn clients to use the auto-props.

We have had this problem with each svn repository the codebase has
lived in and the problem with a solution that relies upon everyone
configuring their clients is that:

1) new people don't necessarily know
2) sometimes people switch clients or machines or whatever and by
accident don't set their clients up correctly.
3) sometimes new extensions come along and we all have to remember to
update our auto-props

The solution we came up with was to have a pre-commit hook that checks
that every text file has the svn:eol-style property set. If it detects
that someone is trying to commit a text file without that property
set, the commit is aborted with an appropriate message.

I have attached the commit hook - what would people think about
getting that added to our svn repository?

RG

Re: svn properties....

Posted by Martin Ritchie <ri...@apache.org>.
Can we all then please set our svn clients to use the auto-props.

Cheers

On 09/11/06, Steve Vinoski <vi...@iona.com> wrote:
> On Nov 9, 2006, at 11:44 AM, Carl Trieloff wrote:
> > Might as well run it on all trees if you are going to go to the
> > effort. Also, Dan do you
> > mind if we check the script into a tools dir somewhere in our svn?
> > I am sure this is some
> > that will come up again.
>
> I created bin and etc directories under trunk/qpid, put Dan's script
> in bin, and put the svn-auto-props file in etc.
>
> --steve
>
> >
> > Carl.
> >
> > Steve Vinoski wrote:
> >>
> >> On Nov 9, 2006, at 10:57 AM, Daniel Kulp wrote:
> >>
> >>>
> >>> I noticed that a lot of files in qpid don't have any svn
> >>> properties set on
> >>> them so they end up with mixed cr/lf issues, wrong mime types when
> >>> browsing, etc....   That's probably not a good thing.
> >>
> >> Dan, good catch. I was about to send a similar note, as last night
> >> I found a bunch of source files containing Windows line endings.
> >>
> >>> I've attached a little bash shell script that I use to fix up
> >>> issues like
> >>> that in a bunch of SVN repositories.   It runs on Linux (maybe on
> >>> Mac as
> >>> well, GNU xargs required) and will reset all the properties for
> >>> the types
> >>> I've been exposed to.   Someone should propable run it on trunk
> >>> to get
> >>> things into a good consistent state and then start from there.
> >>
> >> Unless someone objects, I'll run this script today in the Java
> >> tree and commit it. I'd rather leave the C++ tree to Alan or
> >> Gordon and the Ruby and Python trees to Rafi, unless you guys want
> >> me to take care of those trees too, just let me know.
> >>
> >>> QPID should also define a definite set of auto props that developers
> >>> should be using.   A good starting point may be the CXF ones at:
> >>> http://svn.apache.org/repos/asf/incubator/cxf/trunk/etc/svn-auto-
> >>> props
> >>> they should cover MOST of the stuff encountered.   Not sure about
> >>> the
> >>> ruby/python stuff.
> >>
> >> I've been using the CXF auto props and they work well. I'll commit
> >> a copy of them into the Qpid tree today.
> >>
> >> Thanks Dan!
> >>
> >> --steve
> >>
> >>>
> >>>
> >>> --J. Daniel Kulp
> >>> Principal Engineer
> >>> IONA
> >>> P: 781-902-8727    C: 508-380-7194   F:781-902-8001
> >>> daniel.kulp@iona.com
> >>> <set_svn_properties.sh>
> >>
> >
>
>


-- 
Martin Ritchie

Re: svn properties....

Posted by Steve Vinoski <vi...@iona.com>.
On Nov 9, 2006, at 11:44 AM, Carl Trieloff wrote:
> Might as well run it on all trees if you are going to go to the  
> effort. Also, Dan do you
> mind if we check the script into a tools dir somewhere in our svn?  
> I am sure this is some
> that will come up again.

I created bin and etc directories under trunk/qpid, put Dan's script  
in bin, and put the svn-auto-props file in etc.

--steve

>
> Carl.
>
> Steve Vinoski wrote:
>>
>> On Nov 9, 2006, at 10:57 AM, Daniel Kulp wrote:
>>
>>>
>>> I noticed that a lot of files in qpid don't have any svn  
>>> properties set on
>>> them so they end up with mixed cr/lf issues, wrong mime types when
>>> browsing, etc....   That's probably not a good thing.
>>
>> Dan, good catch. I was about to send a similar note, as last night  
>> I found a bunch of source files containing Windows line endings.
>>
>>> I've attached a little bash shell script that I use to fix up  
>>> issues like
>>> that in a bunch of SVN repositories.   It runs on Linux (maybe on  
>>> Mac as
>>> well, GNU xargs required) and will reset all the properties for  
>>> the types
>>> I've been exposed to.   Someone should propable run it on trunk  
>>> to get
>>> things into a good consistent state and then start from there.
>>
>> Unless someone objects, I'll run this script today in the Java  
>> tree and commit it. I'd rather leave the C++ tree to Alan or  
>> Gordon and the Ruby and Python trees to Rafi, unless you guys want  
>> me to take care of those trees too, just let me know.
>>
>>> QPID should also define a definite set of auto props that developers
>>> should be using.   A good starting point may be the CXF ones at:
>>> http://svn.apache.org/repos/asf/incubator/cxf/trunk/etc/svn-auto- 
>>> props
>>> they should cover MOST of the stuff encountered.   Not sure about  
>>> the
>>> ruby/python stuff.
>>
>> I've been using the CXF auto props and they work well. I'll commit  
>> a copy of them into the Qpid tree today.
>>
>> Thanks Dan!
>>
>> --steve
>>
>>>
>>>
>>> --J. Daniel Kulp
>>> Principal Engineer
>>> IONA
>>> P: 781-902-8727    C: 508-380-7194   F:781-902-8001
>>> daniel.kulp@iona.com
>>> <set_svn_properties.sh>
>>
>


Re: svn properties....

Posted by Martin Ritchie <ri...@apache.org>.
Do you have a list of the offending files? Perhaps my svn client has
regressed. I'd +1 the includsion of an auto-props file that we can
just use.

On 09/11/06, Daniel Kulp <da...@iona.com> wrote:
> On Thursday November 09 2006 11:44 am, Carl Trieloff wrote:
> > Might as well run it on all trees if you are going to go to the effort.
> > Also, Dan do you
> > mind if we check the script into a tools dir somewhere in our svn? I am
> > sure this is some
> > that will come up again.
> >
>
> Not at all.   A slightly different version is already checked into the
> tuscany repository for the same reason.   Probably should add an Apache
> header to it.
>
>
> Dan
>
>
> > Carl.
> >
> > Steve Vinoski wrote:
> > > On Nov 9, 2006, at 10:57 AM, Daniel Kulp wrote:
> > >> I noticed that a lot of files in qpid don't have any svn properties
> > >> set on
> > >> them so they end up with mixed cr/lf issues, wrong mime types when
> > >> browsing, etc....   That's probably not a good thing.
> > >
> > > Dan, good catch. I was about to send a similar note, as last night I
> > > found a bunch of source files containing Windows line endings.
> > >
> > >> I've attached a little bash shell script that I use to fix up issues
> > >> like
> > >> that in a bunch of SVN repositories.   It runs on Linux (maybe on
> > >> Mac as well, GNU xargs required) and will reset all the properties
> > >> for the types
> > >> I've been exposed to.   Someone should propable run it on trunk to
> > >> get things into a good consistent state and then start from there.
> > >
> > > Unless someone objects, I'll run this script today in the Java tree
> > > and commit it. I'd rather leave the C++ tree to Alan or Gordon and
> > > the Ruby and Python trees to Rafi, unless you guys want me to take
> > > care of those trees too, just let me know.
> > >
> > >> QPID should also define a definite set of auto props that developers
> > >> should be using.   A good starting point may be the CXF ones at:
> > >> http://svn.apache.org/repos/asf/incubator/cxf/trunk/etc/svn-auto-pro
> > >>ps they should cover MOST of the stuff encountered.   Not sure about
> > >> the ruby/python stuff.
> > >
> > > I've been using the CXF auto props and they work well. I'll commit a
> > > copy of them into the Qpid tree today.
> > >
> > > Thanks Dan!
> > >
> > > --steve
> > >
> > >> --J. Daniel Kulp
> > >> Principal Engineer
> > >> IONA
> > >> P: 781-902-8727    C: 508-380-7194   F:781-902-8001
> > >> daniel.kulp@iona.com
> > >> <set_svn_properties.sh>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727    C: 508-380-7194   F:781-902-8001
> daniel.kulp@iona.com
>


-- 
Martin Ritchie

Re: svn properties....

Posted by Daniel Kulp <da...@iona.com>.
On Thursday November 09 2006 11:44 am, Carl Trieloff wrote:
> Might as well run it on all trees if you are going to go to the effort.
> Also, Dan do you
> mind if we check the script into a tools dir somewhere in our svn? I am
> sure this is some
> that will come up again.
>

Not at all.   A slightly different version is already checked into the 
tuscany repository for the same reason.   Probably should add an Apache 
header to it.


Dan


> Carl.
>
> Steve Vinoski wrote:
> > On Nov 9, 2006, at 10:57 AM, Daniel Kulp wrote:
> >> I noticed that a lot of files in qpid don't have any svn properties
> >> set on
> >> them so they end up with mixed cr/lf issues, wrong mime types when
> >> browsing, etc....   That's probably not a good thing.
> >
> > Dan, good catch. I was about to send a similar note, as last night I
> > found a bunch of source files containing Windows line endings.
> >
> >> I've attached a little bash shell script that I use to fix up issues
> >> like
> >> that in a bunch of SVN repositories.   It runs on Linux (maybe on
> >> Mac as well, GNU xargs required) and will reset all the properties
> >> for the types
> >> I've been exposed to.   Someone should propable run it on trunk to
> >> get things into a good consistent state and then start from there.
> >
> > Unless someone objects, I'll run this script today in the Java tree
> > and commit it. I'd rather leave the C++ tree to Alan or Gordon and
> > the Ruby and Python trees to Rafi, unless you guys want me to take
> > care of those trees too, just let me know.
> >
> >> QPID should also define a definite set of auto props that developers
> >> should be using.   A good starting point may be the CXF ones at:
> >> http://svn.apache.org/repos/asf/incubator/cxf/trunk/etc/svn-auto-pro
> >>ps they should cover MOST of the stuff encountered.   Not sure about
> >> the ruby/python stuff.
> >
> > I've been using the CXF auto props and they work well. I'll commit a
> > copy of them into the Qpid tree today.
> >
> > Thanks Dan!
> >
> > --steve
> >
> >> --J. Daniel Kulp
> >> Principal Engineer
> >> IONA
> >> P: 781-902-8727    C: 508-380-7194   F:781-902-8001
> >> daniel.kulp@iona.com
> >> <set_svn_properties.sh>

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194   F:781-902-8001
daniel.kulp@iona.com

Re: svn properties....

Posted by Carl Trieloff <cc...@redhat.com>.

Might as well run it on all trees if you are going to go to the effort. 
Also, Dan do you
mind if we check the script into a tools dir somewhere in our svn? I am 
sure this is some
that will come up again.

Carl.

Steve Vinoski wrote:
>
> On Nov 9, 2006, at 10:57 AM, Daniel Kulp wrote:
>
>>
>> I noticed that a lot of files in qpid don't have any svn properties 
>> set on
>> them so they end up with mixed cr/lf issues, wrong mime types when
>> browsing, etc....   That's probably not a good thing.
>
> Dan, good catch. I was about to send a similar note, as last night I 
> found a bunch of source files containing Windows line endings.
>
>> I've attached a little bash shell script that I use to fix up issues 
>> like
>> that in a bunch of SVN repositories.   It runs on Linux (maybe on Mac as
>> well, GNU xargs required) and will reset all the properties for the 
>> types
>> I've been exposed to.   Someone should propable run it on trunk to get
>> things into a good consistent state and then start from there.
>
> Unless someone objects, I'll run this script today in the Java tree 
> and commit it. I'd rather leave the C++ tree to Alan or Gordon and the 
> Ruby and Python trees to Rafi, unless you guys want me to take care of 
> those trees too, just let me know.
>
>> QPID should also define a definite set of auto props that developers
>> should be using.   A good starting point may be the CXF ones at:
>> http://svn.apache.org/repos/asf/incubator/cxf/trunk/etc/svn-auto-props
>> they should cover MOST of the stuff encountered.   Not sure about the
>> ruby/python stuff.
>
> I've been using the CXF auto props and they work well. I'll commit a 
> copy of them into the Qpid tree today.
>
> Thanks Dan!
>
> --steve
>
>>
>>
>> --J. Daniel Kulp
>> Principal Engineer
>> IONA
>> P: 781-902-8727    C: 508-380-7194   F:781-902-8001
>> daniel.kulp@iona.com
>> <set_svn_properties.sh>
>


Re: svn properties....

Posted by John O'Hara <jo...@gmail.com>.
LoL - what was that about scripting and spaces :-)

On 09/11/06, Steve Vinoski <vi...@iona.com> wrote:
>
> I fixed the properties in the java tree. Note that Dan's script
> doesn't handle pathnames with spaces in them ;-) so I also renamed
> "java/client/test/example_ build.xml " to java/client/test/
> example_build.xml to remove the space, hope nobody minds.
>
> --steve
>
> On Nov 9, 2006, at 11:39 AM, Steve Vinoski wrote:
>
> >
> > On Nov 9, 2006, at 10:57 AM, Daniel Kulp wrote:
> >
> >>
> >> I noticed that a lot of files in qpid don't have any svn
> >> properties set on
> >> them so they end up with mixed cr/lf issues, wrong mime types when
> >> browsing, etc....   That's probably not a good thing.
> >
> > Dan, good catch. I was about to send a similar note, as last night
> > I found a bunch of source files containing Windows line endings.
> >
> >> I've attached a little bash shell script that I use to fix up
> >> issues like
> >> that in a bunch of SVN repositories.   It runs on Linux (maybe on
> >> Mac as
> >> well, GNU xargs required) and will reset all the properties for
> >> the types
> >> I've been exposed to.   Someone should propable run it on trunk to
> >> get
> >> things into a good consistent state and then start from there.
> >
> > Unless someone objects, I'll run this script today in the Java tree
> > and commit it. I'd rather leave the C++ tree to Alan or Gordon and
> > the Ruby and Python trees to Rafi, unless you guys want me to take
> > care of those trees too, just let me know.
> >
> >> QPID should also define a definite set of auto props that developers
> >> should be using.   A good starting point may be the CXF ones at:
> >> http://svn.apache.org/repos/asf/incubator/cxf/trunk/etc/svn-auto-
> >> props
> >> they should cover MOST of the stuff encountered.   Not sure about the
> >> ruby/python stuff.
> >
> > I've been using the CXF auto props and they work well. I'll commit
> > a copy of them into the Qpid tree today.
> >
> > Thanks Dan!
> >
> > --steve
> >
> >>
> >>
> >> --
> >> J. Daniel Kulp
> >> Principal Engineer
> >> IONA
> >> P: 781-902-8727    C: 508-380-7194   F:781-902-8001
> >> daniel.kulp@iona.com
> >> <set_svn_properties.sh>
> >
>
>

Re: svn properties....

Posted by Steve Vinoski <vi...@iona.com>.
I fixed the properties in the java tree. Note that Dan's script  
doesn't handle pathnames with spaces in them ;-) so I also renamed  
"java/client/test/example_ build.xml " to java/client/test/ 
example_build.xml to remove the space, hope nobody minds.

--steve

On Nov 9, 2006, at 11:39 AM, Steve Vinoski wrote:

>
> On Nov 9, 2006, at 10:57 AM, Daniel Kulp wrote:
>
>>
>> I noticed that a lot of files in qpid don't have any svn  
>> properties set on
>> them so they end up with mixed cr/lf issues, wrong mime types when
>> browsing, etc....   That's probably not a good thing.
>
> Dan, good catch. I was about to send a similar note, as last night  
> I found a bunch of source files containing Windows line endings.
>
>> I've attached a little bash shell script that I use to fix up  
>> issues like
>> that in a bunch of SVN repositories.   It runs on Linux (maybe on  
>> Mac as
>> well, GNU xargs required) and will reset all the properties for  
>> the types
>> I've been exposed to.   Someone should propable run it on trunk to  
>> get
>> things into a good consistent state and then start from there.
>
> Unless someone objects, I'll run this script today in the Java tree  
> and commit it. I'd rather leave the C++ tree to Alan or Gordon and  
> the Ruby and Python trees to Rafi, unless you guys want me to take  
> care of those trees too, just let me know.
>
>> QPID should also define a definite set of auto props that developers
>> should be using.   A good starting point may be the CXF ones at:
>> http://svn.apache.org/repos/asf/incubator/cxf/trunk/etc/svn-auto- 
>> props
>> they should cover MOST of the stuff encountered.   Not sure about the
>> ruby/python stuff.
>
> I've been using the CXF auto props and they work well. I'll commit  
> a copy of them into the Qpid tree today.
>
> Thanks Dan!
>
> --steve
>
>>
>>
>> -- 
>> J. Daniel Kulp
>> Principal Engineer
>> IONA
>> P: 781-902-8727    C: 508-380-7194   F:781-902-8001
>> daniel.kulp@iona.com
>> <set_svn_properties.sh>
>


Re: svn properties....

Posted by Steve Vinoski <vi...@iona.com>.
On Nov 9, 2006, at 10:57 AM, Daniel Kulp wrote:

>
> I noticed that a lot of files in qpid don't have any svn properties  
> set on
> them so they end up with mixed cr/lf issues, wrong mime types when
> browsing, etc....   That's probably not a good thing.

Dan, good catch. I was about to send a similar note, as last night I  
found a bunch of source files containing Windows line endings.

> I've attached a little bash shell script that I use to fix up  
> issues like
> that in a bunch of SVN repositories.   It runs on Linux (maybe on  
> Mac as
> well, GNU xargs required) and will reset all the properties for the  
> types
> I've been exposed to.   Someone should propable run it on trunk to get
> things into a good consistent state and then start from there.

Unless someone objects, I'll run this script today in the Java tree  
and commit it. I'd rather leave the C++ tree to Alan or Gordon and  
the Ruby and Python trees to Rafi, unless you guys want me to take  
care of those trees too, just let me know.

> QPID should also define a definite set of auto props that developers
> should be using.   A good starting point may be the CXF ones at:
> http://svn.apache.org/repos/asf/incubator/cxf/trunk/etc/svn-auto-props
> they should cover MOST of the stuff encountered.   Not sure about the
> ruby/python stuff.

I've been using the CXF auto props and they work well. I'll commit a  
copy of them into the Qpid tree today.

Thanks Dan!

--steve

>
>
> -- 
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727    C: 508-380-7194   F:781-902-8001
> daniel.kulp@iona.com
> <set_svn_properties.sh>