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
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.
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
http://www.frecanse.com/sh//images/mywork.html
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 sv
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 exampl
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
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 clie
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
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 wi
> 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 rea
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
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 yo
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
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-
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 inf
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 t
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
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 goo
19 matches
Mail list logo
