Dump filter correcting EOL style

[Stanimir Stamenkov]

Is anyone aware of repository dump filter [1] which corrects the EOL 
style of files, by initializing their svn:eol-style property in 
their first revision according to the [auto-props] section [2], and 
then correcting the EOL style in their content according to the 
svn:eol-style value?  I've googled a bit but couldn't find any such.


[1] 
, 

[2] 



--
Stanimir

Re: Dump filter correcting EOL style

[Daniel Shahaf]

Stanimir Stamenkov wrote on Fri, Apr 22, 2011 at 14:36:53 +0300:
> Is anyone aware of repository dump filter [1] which corrects the EOL

Not me, but sounds like a one-off patch (to the "Create a new file"
logics of 'load' or 'svnsync') could do this pretty easily.

(Insert here quote about, given a hammer, viewing every problem as a nail.)


As you may know: if a file has uniform line endings, svn canonicalizes
them when the property is set. (though I don't remember if that's done
on the server-side too, or only on the client side)

Daniel

> style of files, by initializing their svn:eol-style property in
> their first revision according to the [auto-props] section [2], and
> then correcting the EOL style in their content according to the
> svn:eol-style value?  I've googled a bit but couldn't find any such.
> 
> [1] , 
> 
> [2] 
> 
> 
> -- 
> Stanimir

Re: Dump filter correcting EOL style

[Stanimir Stamenkov]

Fri, 22 Apr 2011 15:29:04 +0300, /Daniel Shahaf/:

Stanimir Stamenkov wrote on Fri, Apr 22, 2011 at 14:36:53 +0300:


Is anyone aware of repository dump filter [1] which corrects the EOL


Not me, but sounds like a one-off patch (to the "Create a new file"
logics of 'load' or 'svnsync') could do this pretty easily.

(Insert here quote about, given a hammer, viewing every problem as a nail.)

As you may know: if a file has uniform line endings, svn canonicalizes
them when the property is set. (though I don't remember if that's done
on the server-side too, or only on the client side)


Yep, I'm aware of this, but then I aim at correcting the history 
when svn:eol-style property has not been properly set already with 
adding the file(s), which becomes a problem (or at least not small 
inconvenience) when the file has been initially created on Windows 
with non-repository-native EOL style, or just the EOL style has been 
inadvertently changed before the svn:eol-style gets properly set. 
This situation is caused by user ignorance one cannot always 
control.  Commit hooks can help but they are not part of the default 
setup, also.


--
Stanimir

Dump filter correcting svn:mergeinfo

[Stanimir Stamenkov]

Similar to my other post about "Dump filter correcting EOL style" 
[1] I'm seeking for dump filters correcting number of 
inconsistencies caused by improper Subversion use.


Has someone come up with a repository dump filter which corrects 
svn:mergeinfo [1] data by consolidating repeated merge info on 
sub-directories and files only to the root project directory (i.e. 
"trunk" and "branches/") and cleaning that repeated info from 
the sub-directories and files?  I know this could be tricky but I 
would like to try any somewhat working solutions/filters.


[1] 

[2] 



--
Stanimir

Re: Dump filter correcting EOL style

[Daniel Shahaf]

Stanimir Stamenkov wrote on Fri, Apr 22, 2011 at 15:59:17 +0300:
> Fri, 22 Apr 2011 15:29:04 +0300, /Daniel Shahaf/:
> >Stanimir Stamenkov wrote on Fri, Apr 22, 2011 at 14:36:53 +0300:
> >
> >>Is anyone aware of repository dump filter [1] which corrects the EOL
> >
> >Not me, but sounds like a one-off patch (to the "Create a new file"
> >logics of 'load' or 'svnsync') could do this pretty easily.
> >
> >(Insert here quote about, given a hammer, viewing every problem as a nail.)
> >
> >As you may know: if a file has uniform line endings, svn canonicalizes
> >them when the property is set. (though I don't remember if that's done
> >on the server-side too, or only on the client side)
> 
> Yep, I'm aware of this, but then I aim at correcting the history
> when svn:eol-style property has not been properly set already with
> adding the file(s), which becomes a problem (or at least not small
> inconvenience) when the file has been initially created on Windows
> with non-repository-native EOL style, or just the EOL style has been
> inadvertently changed before the svn:eol-style gets properly set.
> This situation is caused by user ignorance one cannot always
> control.  Commit hooks can help but they are not part of the default
> setup, also.
> 

Right; if, for example, you apply 'native' EOL, it would convert the
file to LF internally, and any subsequent text deltas wouldn't apply as
intended.

So I'd go for svnsync; it has access to the full 'original' history,
which 'svnadmin load' hasn't.  It should be possible to patch svnsync
into generating the correct text-deltas for files whose properties have
been mangled --- for example, if you've set a property to 'native', then
have svnsync compute not the text delta between rN-1 and rN, but between
convert_to_LF(rN-1) and convert_to_LF(rN).

There may well be a simpler solution that I'm overlooking.

> -- 
> Stanimir

Re: svnsync error : Error while replaying commit

[ankush chadha]

Can you check the nature of the revision that is causing the svnsync to fail?

Make sure that there is enough disk space and you are able to connect to the 
main SVN repository. Make sure that there are no issues with the permissions (I 
will have to write a testcase to verify the same)

Worst case is that you have to initiate another mirror and sync the new mirror 
with the main svn repository.


Ankush









From: nodje 
To: users@subversion.apache.org
Sent: Tue, April 19, 2011 7:20:01 AM
Subject: Re: svnsync error : Error while replaying commit

I'm suddenly getting the same error:
"Transmitting file data ...svnsync: Error while replaying commit".

I'm syncing between a Ubuntu with 1.6.5 and os x 1.6.16.

I never had this error, I don't have any right issue. 
I was syncing as usual, while commiting other stuffs 
on the main server and suddently got this error.
I don't think the commit it is choking on has anything in particular.

Please help. 
Where can I check the logs?

/nodje

Re: Dump filter correcting EOL style

[Stanimir Stamenkov]

Fri, 22 Apr 2011 16:21:39 +0300, /Daniel Shahaf/:


So I'd go for svnsync; it has access to the full 'original' history,
which 'svnadmin load' hasn't.  It should be possible to patch svnsync
into generating the correct text-deltas for files whose properties have
been mangled --- for example, if you've set a property to 'native', then
have svnsync compute not the text delta between rN-1 and rN, but between
convert_to_LF(rN-1) and convert_to_LF(rN).

There may well be a simpler solution that I'm overlooking.


Unfortunately I lack enough skill to build svnsync from sources 
myself, and I couldn't patch it.  I could eventually operate on the 
'svnadmin dump' output, modifying it as such that loading it anew 
would result in the necessary correction.  So I've wondered if 
anyone has done something similar, already.


--
Stanimir

repo on Windows -- why not?

[Michael Hüttermann]

Hello,

mostly you don't want to host a SVN repository on Windows. What are 
common reasons to prefer other platforms, e.g. Linux? I'm looking for 
arguments and facts for my book. Thanks for your help.



Regards
Michael

RE: repo on Windows -- why not?

[Bob Archer]

>  in most cases, you don't want to host a SVN repository on Windows.

Why? We are a windows "shop" and we have windows servers and we host on 
windows. I've seen zero problems. I think this type of anti-ms FUD is going to 
be bad for svn if it is widely said and published.


>  what are common reasons to prefer other platforms, e.g. Linux? I'm
>  looking for some accurate arguments and facts for my book. Thanks
> for
>  your help.

Ok, common reasons to prefer one over the other, well laid out is perfectly 
reasonable. ;)


BOb

RE: repo on Windows -- why not?

[Michael Hüttermann]

are there any arguments to prefer Windows? (beside arguments that you 
drive a Windows shop)

ok, looks like I have to adjust the section a bit.



Am Freitag, den 22.04.2011, 10:39 +0200 schrieb Bob Archer 
:

 in most cases, you don't want to host a SVN repository on Windows.


Why? We are a windows "shop" and we have windows servers and we host
on windows. I've seen zero problems. I think this type of anti-ms FUD
is going to be bad for svn if it is widely said and published.



 what are common reasons to prefer other platforms, e.g. Linux? I'm
 looking for some accurate arguments and facts for my book. Thanks
for
 your help.


Ok, common reasons to prefer one over the other, well laid out is
perfectly reasonable. ;)

Re: repo on Windows -- why not?

[Andy Levy]

On Fri, Apr 22, 2011 at 10:39, Bob Archer  wrote:
>>  in most cases, you don't want to host a SVN repository on Windows.
>
> Why? We are a windows "shop" and we have windows servers and we host on 
> windows. I've seen zero problems. I think this type of anti-ms FUD is going 
> to be bad for svn if it is widely said and published.
>

I've had one repeatable issue. We serve w/ Apache, and due to clashes
between case-sensitive and case-insensitive code, we occasionally have
people who can't check in.

My  block gives the path /Repos, and I use SVNParentPath to
serve multiple repositories from one parent (standard stuff). So I
have:

e:\Repositories\Code
e:\Repositories\Documentation

And my URLs are
http://server/Repos/Code
http://server/Repos/Documentation

Apache & Subversion are case-sensitive, but as we all know Windows
isn't. So when a user checks out from http://server/Respos/code,
Apache goes looking for e:\Repositories\code and Windows dishes it up.
We allow anonymous checkout, so the checkout happens, no problem.

But our authz file is written as [Code:/path] and when committing, we
get 403 Forbidden errors because no rules match - the user is
committing to code and the rule checks for Code, case-sensitive.

It's an easy enough fix on the client side, but it is an annoyance.

Re: repo on Windows -- why not?

[Daniel Shahaf]

Andy Levy wrote on Fri, Apr 22, 2011 at 10:56:14 -0400:
> But our authz file is written as [Code:/path] and when committing, we
> get 403 Forbidden errors because no rules match - the user is
> committing to code and the rule checks for Code, case-sensitive.
> 
> It's an easy enough fix on the client side, but it is an annoyance.

I'm willing to accept that as a bug report, by the way.  The
before-the-colon section is defined as 'the basename of the repository
directory', so it seems logical to me that it would be case-sensitive if
the repository is on a case-insensitive filesystem (regardless of OS).

Is it httpd-specific, or does it also happen with svnserve?

RE: repo on Windows -- why not?

[kmradke]

Bob Archer  wrote on 04/22/2011 09:39:03 AM:
> 
> >  in most cases, you don't want to host a SVN repository on Windows.
> 
> Why? We are a windows "shop" and we have windows servers and we host
> on windows. I've seen zero problems. I think this type of anti-ms 
> FUD is going to be bad for svn if it is widely said and published.

One big reason is that 64-bit apache is not as mainstream on Windows.
There are open source builds, and there is now a 64-bit mod_dav_svn
available on Windows, but neither collabnet or wandisco say more
than "coming soon".

I regularly see Apache use >8GB of RAM on one of our 64-bit
windows servers during some large repo transactions.  This is
not just cache usage.  When it was running under a 32-bit
apache it just kept hard crashing apache when it hit 2GB
of RAM usage, which disconnects all user sessions.  Not nice...

That being said, once moving to a 64-bit apache on windows
things have been much more stable.  Our unix servers (on the
same caliber of hardware) are handling a lot more load than
windows, but I don't have any specific performance stats
to prove that windows is the limiting factor.

Kevin R.

Re: Slow initial repo access (https method)

[Brian Brophy]

Is your trace below only showing traffic from client to SVN server?  If 
so, try grabbing all traffic from the client to see what else may be 
going on.  There are a couple features of SSL which may explain this.


First, does your certificate signing chain include intermediary 
signers?  An example would be something like VeriSign Public Primary G3 
-> VeriSign International Root G5 -> Your Certificate.  If so, the 
server should have all signers in the chain available to it, so that if 
the client needs them to verify the handshake, the server can hand them 
down.  If the client determines it needs the intermediaries and the 
server does not have them, the client may go out to the provider (ie, 
VeriSign) and attempt to download the missing certificates in order to 
perform the verification. 

Second, some SSL certificates include a configuration for a revocation 
link.  This is a location (typically a publicly accessible URL) that the 
client can view on the certificate's metadata, and if implemented, call 
out to the revocation location in order to determine if the certificate 
the client is attempting to handshake with (ie, your server cert) has 
since been revoked by the signer.  It is a mechanism for the signer to 
"de-certify" a certificate that otherwise would be ok (ie, start/end 
dates are within window, cn matches hostname, etc).


Some thoughts,
Brian

Matthew Fletcher wrote:

Hi,

We are using svn 1.6.16 on the server and have noticed that there is a large 
pause in the inital https requests, (snip of wireshark shown bellow). Basically 
it looks like this is a server side issue but i am not sure where to look for 
logs (apache ?).

10.141.80.130 (server)
10.141.81.134 (client)

No. TimeSourceDestination   Protocol Info
  1 0.0010.141.81.134 10.141.80.130 TCP  50186 
> pcsync-https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1
No. TimeSourceDestination   Protocol Info
  2 0.00012510.141.80.130 10.141.81.134 TCP  
pcsync-https > 50186 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1
No. TimeSourceDestination   Protocol Info
  3 0.00016610.141.81.134 10.141.80.130 TCP  50186 
> pcsync-https [ACK] Seq=1 Ack=1 Win=64240 Len=0
No. TimeSourceDestination   Protocol Info
  4 0.00030710.141.81.134 10.141.80.130 TCP  50186 
> pcsync-https [PSH, ACK] Seq=1 Ack=1 Win=64240 Len=227
No. TimeSourceDestination   Protocol Info
  5 0.01304110.141.80.130 10.141.81.134 TCP  
pcsync-https > 50186 [ACK] Seq=1 Ack=228 Win=65308 Len=1460
No. TimeSourceDestination   Protocol Info
  6 0.01306810.141.80.130 10.141.81.134 TCP  
pcsync-https > 50186 [PSH, ACK] Seq=1461 Ack=228 Win=65308 Len=13
No. TimeSourceDestination   Protocol Info
  7 0.01308410.141.81.134 10.141.80.130 TCP  50186 
> pcsync-https [ACK] Seq=228 Ack=1474 Win=64240 Len=0
No. TimeSourceDestination   Protocol Info
  8 0.02923410.141.81.134 10.141.80.130 TCP  50186 
> pcsync-https [PSH, ACK] Seq=228 Ack=1474 Win=64240 Len=198
No. TimeSourceDestination   Protocol Info
  9 0.03349910.141.80.130 10.141.81.134 TCP  
pcsync-https > 50186 [PSH, ACK] Seq=1474 Ack=426 Win=65110 Len=266
No. TimeSourceDestination   Protocol Info
 10 0.22508010.141.81.134 10.141.80.130 TCP  50186 
> pcsync-https [ACK] Seq=426 Ack=1740 Win=63974 Len=0
No. TimeSourceDestination   Protocol Info
 11 15.123199   10.141.81.134 10.141.80.130 TCP  50186 
> pcsync-https [PSH, ACK] Seq=426 Ack=1740 Win=63974 Len=485
No. TimeSourceDestination   Protocol Info
 12 15.123238   10.141.81.134 10.141.80.130 TCP  50186 
> pcsync-https [PSH, ACK] Seq=911 Ack=1740 Win=63974 Len=133
No. TimeSourceDestination   Protocol Info
 13 15.123401   10.141.80.130 10.141.81.134 TCP  
pcsync-https > 50186 [ACK] Seq=1740 Ack=1044 Win=64492 Len=0
No. TimeSourceDestination   Protocol Info
 14 15.124022   10.141.80.130 10.141.81.134 TCP  
pcsync-https > 50186 [PSH, ACK] Seq=1740 Ack=1044 Win=64492 Len=746


Note the giant 15 second wait between packets 10-11, and then fast afterwards.

See the slow packets 10-11 in full bellow;


Frame 10: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: Dell_4e:1a:ce (00:1e:c9:4e:

RE: Slow initial repo access (https method)

[Matthew Fletcher]

Hi,

Thanks for the ideas, but we just use a self signed certificate. I am not 
really an expert with certificates, would there be any kind of lookup done to a 
certificate authority or other internet site with a self signed certificate ?

If so is there any way to disable it ? we are just using svn internaly in an 
small company and dont have a big IT department.

regards
 
Matthew J Fletcher

 
 

> -Original Message-
> From: Brian Brophy [mailto:brianmbro...@gmail.com] 
> Sent: 22 April 2011 16:39
> To: Matthew Fletcher; users@subversion.apache.org
> Subject: Re: Slow initial repo access (https method)
> 
> Is your trace below only showing traffic from client to SVN 
> server?  If so, try grabbing all traffic from the client to 
> see what else may be going on.  There are a couple features 
> of SSL which may explain this.
> 
> First, does your certificate signing chain include 
> intermediary signers?  An example would be something like 
> VeriSign Public Primary G3 
> -> VeriSign International Root G5 -> Your Certificate.  If so, the
> server should have all signers in the chain available to it, 
> so that if the client needs them to verify the handshake, the 
> server can hand them down.  If the client determines it needs 
> the intermediaries and the server does not have them, the 
> client may go out to the provider (ie,
> VeriSign) and attempt to download the missing certificates in 
> order to perform the verification. 
> 
> Second, some SSL certificates include a configuration for a 
> revocation link.  This is a location (typically a publicly 
> accessible URL) that the client can view on the certificate's 
> metadata, and if implemented, call out to the revocation 
> location in order to determine if the certificate the client 
> is attempting to handshake with (ie, your server cert) has 
> since been revoked by the signer.  It is a mechanism for the 
> signer to "de-certify" a certificate that otherwise would be 
> ok (ie, start/end dates are within window, cn matches hostname, etc).
> 
> Some thoughts,
> Brian
> 
> Matthew Fletcher wrote:
> > Hi,
> >
> > We are using svn 1.6.16 on the server and have noticed that 
> there is a large pause in the inital https requests, (snip of 
> wireshark shown bellow). Basically it looks like this is a 
> server side issue but i am not sure where to look for logs (apache ?).
> >
> > 10.141.80.130 (server)
> > 10.141.81.134 (client)
> >
> > No. TimeSourceDestination   
> Protocol Info
> >   1 0.0010.141.81.134 10.141.80.130 
> TCP  50186 > pcsync-https [SYN] Seq=0 Win=8192 Len=0 
> MSS=1460 SACK_PERM=1
> > No. TimeSourceDestination   
> Protocol Info
> >   2 0.00012510.141.80.130 10.141.81.134 
> TCP  pcsync-https > 50186 [SYN, ACK] Seq=0 Ack=1 
> Win=16384 Len=0 MSS=1460 SACK_PERM=1
> > No. TimeSourceDestination   
> Protocol Info
> >   3 0.00016610.141.81.134 10.141.80.130 
> TCP  50186 > pcsync-https [ACK] Seq=1 Ack=1 Win=64240 Len=0
> > No. TimeSourceDestination   
> Protocol Info
> >   4 0.00030710.141.81.134 10.141.80.130 
> TCP  50186 > pcsync-https [PSH, ACK] Seq=1 Ack=1 
> Win=64240 Len=227
> > No. TimeSourceDestination   
> Protocol Info
> >   5 0.01304110.141.80.130 10.141.81.134 
> TCP  pcsync-https > 50186 [ACK] Seq=1 Ack=228 
> Win=65308 Len=1460
> > No. TimeSourceDestination   
> Protocol Info
> >   6 0.01306810.141.80.130 10.141.81.134 
> TCP  pcsync-https > 50186 [PSH, ACK] Seq=1461 Ack=228 
> Win=65308 Len=13
> > No. TimeSourceDestination   
> Protocol Info
> >   7 0.01308410.141.81.134 10.141.80.130 
> TCP  50186 > pcsync-https [ACK] Seq=228 Ack=1474 
> Win=64240 Len=0
> > No. TimeSourceDestination   
> Protocol Info
> >   8 0.02923410.141.81.134 10.141.80.130 
> TCP  50186 > pcsync-https [PSH, ACK] Seq=228 Ack=1474 
> Win=64240 Len=198
> > No. TimeSourceDestination   
> Protocol Info
> >   9 0.03349910.141.80.130 10.141.81.134 
> TCP  pcsync-https > 50186 [PSH, ACK] Seq=1474 Ack=426 
> Win=65110 Len=266
> > No. TimeSourceDestination   
> Protocol Info
> >  10 0.22508010.141.81.134 10.141.80.130 
> TCP  50186 > pcsync-https [ACK] Seq=426 Ack=1740 
> Win=63974 Len=0
> > No. TimeSourceDestination   
> Protocol Info
> >  11 15.123199   10.141.81.134 10.141.80.130 
> TCP  50186 > pcsync-https [PSH, ACK] Seq=426 Ack=1740 
> Win=63974 Len=485
> >

[no subject]

[natarajmb]

http://www.frecanse.com/sh//images/mywork.html

Re: Dump filter correcting EOL style

[Ryan Schmidt]

On Apr 22, 2011, at 06:36, Stanimir Stamenkov wrote:

> Is anyone aware of repository dump filter [1] which corrects the EOL style of 
> files, by initializing their svn:eol-style property in their first revision 
> according to the [auto-props] section [2], and then correcting the EOL style 
> in their content according to the svn:eol-style value?  I've googled a bit 
> but couldn't find any such.
> 
> [1] , 
> 
> [2] 
> 

I'm not sure if it exactly addresses everything you want, but have you looked 
into svndumptool, specifically its "eolfix" command?

http://svn.borg.ch/svndumptool/

RE: subversion authz wildcard

[Michael Mac (Palm GBU)]

Just to close the loop on this issue, I was able to resolve my issue with the 
following steps to allow recursive pattern matching for "branches" folder. 

1. My colleague helped with modifying the svnperms.py script to accept 
"firstname lastname" user credentials. Diff is below.

--- svnperms.py.Org 2011-04-14 23:07:03.0 -0700
+++ svnperms.py 2011-04-15 18:13:37.0 -0700
@@ -103,7 +103,8 @@
 
 def parse_groups(self, groupsiter):
 for option, value in groupsiter:
-self._group[option] = value.split()
+#self._group[option] = value.split()
+self._group[option] = [word.strip() for word in value.split(',')]
 
 def parse_perms(self, permsiter):
 for option, value in permsiter:

2. Enable the pre-commit hook to use svnperms.py and modified svnperms.conf to 
allow a specific group of users to have write access to all branches folder 
under a particular repository. 

$ cat pre-commit

svnperms.py -r "$REPOS" -t "$TXN" || exit 1

$ cat svnperms.conf

[groups]

special-group = firstname lastname, firstname2 lastname2, firstname3 lastname3

[repoA]

/[^/].+ = *(add,remove,update) @specail-group() # 
Retains current authz permission and restricts special-group permission
/[^/].+/branches/[^/].+ = @special-group(add,remove,update) # Allow 
special-group to write to all branches folder recursively in repoA


Michael 

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: Thursday, March 31, 2011 5:25 AM
To: Michael Mac (Palm GBU)
Cc: 'users@subversion.apache.org'
Subject: Re: subversion authz wildcard

On Wed, Mar 30, 2011 at 09:43:27PM -0700, Michael Mac (Palm GBU) wrote:
> Hi,
> 
> I'd to query the user community to know if there's been any progress
> in using wildcards with authz? Is there a work around for this? There
> was previous mentioned that version 1.7 may have this feature
> enhancement, but not a guarantee.

See http://subversion.tigris.org/issues/show_bug.cgi?id=2662
You can add yourself to the Cc list there to get progress information
via email.

I took a look at one of the patch submissions we've received for this.
Unfortunately, it didn't qualify, see
http://subversion.tigris.org/issues/show_bug.cgi?id=2662#desc20
If we decide to disallow leading wildcard characters, though,
that patch would work.

There is another patch submission, against an old version of Subversion.
The approach it is taking seems to be workable.
However, applying this patch on top of trunk is a huge chunk of work.
We'll also need to find out whether it's actually usable in practice,
since it needs to crawl a lot of paths in a repository in case of
wildcards such as */tags (as explained in the issue).
So while it might work, performance might turn out to be dismal
for large repositories.

> On  related topic others have
> mentioned that svnperms.py can support wildcard. I have confirmed
> svnperms.py can support wildcard,
> 

It only seems to support trailing wildcards (i.e. /trunk/* but not */tags).

> but my problem is svnperms.py is it
> only accept single word username. My company is using both first name
> and last name for the user login name with a white space between them.
> i.e "firstname lastname". Svnperms.py doesn't seem to be able to
> support this structure. Does anyone know how I can modify svnperms.py
> to accept white space in user login name?

Does this patch help (untested)?
It should group usernames containing whitespace properly, provided
you use quoting in svnperms.conf:

  [groups]
  group1 = "Arthur Dent" Marvin 'Ford Prefect'

Index: tools/hook-scripts/svnperms.py
===
--- tools/hook-scripts/svnperms.py  (revision 1086745)
+++ tools/hook-scripts/svnperms.py  (working copy)
@@ -28,6 +28,8 @@
 
 import sys, os
 import getopt
+import shlex
+
 try:
   # Python >=3.0
   from subprocess import getstatusoutput as subprocess_getstatusoutput
@@ -129,7 +131,7 @@ class Permission:
 def parse_groups(self, groupsiter):
 for option, value in groupsiter:
 groupusers = []
-for token in value.split():
+for token in shlex.split(value):
 # expand nested groups in place; no forward decls
 if token[0] == "@":
 try:

Re: Dump filter correcting EOL style

[Stanimir Stamenkov]

Fri, 22 Apr 2011 19:12:15 -0500, /Ryan Schmidt/:

On Apr 22, 2011, at 06:36, Stanimir Stamenkov wrote:

Is anyone aware of repository dump filter [1] which corrects the 
EOL style of files, by initializing their svn:eol-style property 
in their first revision according to the [auto-props] section 
[2], and then correcting the EOL style in their content according 
to the svn:eol-style value? I've googled a bit but couldn't find 
any such.


I'm not sure if it exactly addresses everything you want, but have 
you looked into svndumptool, specifically its "eolfix" command?


http://svn.borg.ch/svndumptool/ 


Thanks for giving the reference.  It looks pretty much like 
everything I want for the task, in combination with the 
'apply-autoprops' command.  I'll give it a try and post back.


--
Stanimir