On 31 August 2016 at 14:54, Vacelet, Manuel wrote:
> On Wed, Aug 31, 2016 at 12:37 PM, Ivan Zhakov wrote:
>>
>> On 31 August 2016 at 13:28, Vacelet, Manuel
>> wrote:
>> > On Wed, Aug 31, 2016 at 12:19 PM, Ivan Zhakov
>> > wrote:
>> >>
>>
On 31 August 2016 at 13:28, Vacelet, Manuel wrote:
> On Wed, Aug 31, 2016 at 12:19 PM, Ivan Zhakov wrote:
>>
>>
>> > - Why this behaviour changed between 1.6 and newer ?
>> It was bug before Subversion 1.7.9. The problem was that client tried
>> to read some i
On 31 August 2016 at 13:04, Vacelet, Manuel wrote:
> On Thu, Aug 25, 2016 at 11:29 AM, Ivan Zhakov wrote:
>>
>> On 25 August 2016 at 12:19, Vacelet, Manuel
>> wrote:
[...]
>
> Ivan,
>
Hi Manuel,
> I don't think it the same issue as in my case, the users a
On 25 August 2016 at 12:30, Stefan Hett wrote:
> On 8/25/2016 11:13 AM, Ivan Zhakov wrote:
>>
>> On 25 August 2016 at 11:50, Vacelet, Manuel
>> wrote:
>>>
>>> On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
>>> wrote:
>>>>
>>&
On 25 August 2016 at 12:19, Vacelet, Manuel wrote:
> On Thu, Aug 25, 2016 at 11:13 AM, Ivan Zhakov wrote:
>>
>> On 25 August 2016 at 11:50, Vacelet, Manuel
>> wrote:
>> > On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel
>> > wrote:
>> >>
&
I can delete /tags with svn 1.7, 1.8 & svn 1.9
> client but not with svn 1.6.
> I failed to find in 1.7 release note something that explains this change.
>
It was bug in Subversion 1.7 that remove operation requires access to
repository root:
SVN-4219: svn delete fails with "403 Forbidden" if root is not readable [1]
This problem was fixed in Subversion 1.8. It's not server-side change.
It was client problem accessing repository root, while it's not
needed.
[1] https://issues.apache.org/jira/browse/SVN-4219
--
Ivan Zhakov
the working copy to another location, checkout, when update it asked
again.
How could I reset/remove/troubleshoot it?
What is it for, anyway?
Have a great time.
Saudações,
Ivan de Miranda
To: ivang...@hotmail.com
From: supp...@beanstalkapp.com
Subject: Re: I'm confused about how something wo
On 11 August 2016 at 17:30, Ivan Zhakov wrote:
> On 27 July 2016 at 14:09, Ivan Zhakov wrote:
>> 2016-07-26 16:10 GMT+03:00 Niemann, Hartmut :
>>>
>>> Hello!
>>> The command line client of Tortoise Subversion:
>>>
>>> D:\>svn --version
>
On 27 July 2016 at 14:09, Ivan Zhakov wrote:
> 2016-07-26 16:10 GMT+03:00 Niemann, Hartmut :
>>
>> Hello!
>> The command line client of Tortoise Subversion:
>>
>> D:\>svn --version
>> svn, version 1.9.4 (r1740329)
>>
>>compiled Apr 24 201
e the change in the dumpfile was a bit different: the
>> Node-path / Node-kind / Node-action lines were still there, but the
>> Text-content lines were gone (if you dumped again from the new
>> repository, the entire block with Node-path etc would be gone). See
>> http://svn.haxx.se/dev/archive-2015-09/0269.shtml for the entire
>> (long) discussion, which lead to the bugfix for 1.9.3.
>
> Ah right. Now i recall. Thanks for digging that up. So unless I observe any
> issues, I take it that the change I observed is just a benign one.
>
Just for the records SVN-4598 [1]: No-op changes no longer dumped by
'svnadmin dump' in 1.9
[1] https://issues.apache.org/jira/browse/SVN-4598
--
Ivan Zhakov
ZD.itm -r3340 --xml
>
> Why does svn log fail on the text output but handles the same amount if it is
> XML?
>
The actual error is:
OS 8: Not enough storage is available to process this command.
Could you try run 'svn log' with redirected output, i.e.:
svn log ZD.itm -r3340 >test.txt
--
Ivan Zhakov
[please use plain-text formatting as documented in Community Guide [1]]
https://subversion.apache.org/docs/community-guide/mailing-lists.html#encodings
On 9 May 2016 at 12:05, Stefan Hett wrote:
>> On 5/9/2016 10:55 AM, Stefan Hett wrote:
>>> On 5/9/2016 10:09 AM, Iv
uld differ in that the effected version
> would be 1.9.x - not 1.8.x - aka: no regression)?
>
Could you please provide reproduction script using command line
client? As far I understand the problem in 'Java-SSL-Tunnel', not in
Subversion itself.
--
Ivan Zhakov
t version of TortoiseSVN 1.9.x do you use? Output of 'svn
--version --verbose' command would be useful.
If I remember correctly some TortoiseSVN builds was compiled using
static runtime and this caused some problems with stdout flushing.
--
Ivan Zhakov
On 6 February 2016 at 01:49, Michael Osipov wrote:
> Am 2016-02-05 um 22:10 schrieb Ivan Zhakov:
>>
>> On 5 February 2016 at 23:48, Michael Osipov wrote:
>>>
>>> Am 2016-02-05 um 20:31 schrieb Ivan Zhakov:
>>>>
>>>>
>>>> On
On 5 February 2016 at 23:48, Michael Osipov wrote:
> Am 2016-02-05 um 20:31 schrieb Ivan Zhakov:
>>
>> On 5 February 2016 at 21:38, Michael Osipov wrote:
>>>
>>> Hi folks,
>>>
>>> Subversion advised me to report this.
>>>
>>>
o-svn
>
> The repo is available here [1], the crash files are here [2].
> The issue can always be reproduced, it does not require to run the tests
> with Maven on Maven Wagon.
>
I cannot reproduce:
[[[
svn --non-interactive file:///D:/Ivan/temp/repos/test-repo-svn
dummy
C:\Pr
>
> START: checksum-test.exe
> PASS: checksum-test 1: checksum parse
> PASS: checksum-test 2: checksum emptiness
> PASS: checksum-test 3: zero checksum matching
> svn_tests: E26: Decompressed data doesn't match expected size or crc with
> blocksize 17: Found crc32=0x3a74e3ee, size=241883.
> Verify your ZLib installation, as this should never happen
> FAIL: checksum-test 4: zlib expansion test (zlib regression)
Zlib has known bug in assembly optimized code. Just disable assembly
optimized code in zlib and everything should be fine.
--
Ivan Zhakov
re not packed alongside the archive.
> If that would be helpful for you I could repackage them so you can use that
> for testing.
>
I wouldn't recommend to use Apache HTTP Server and Subversion modules
obtained from different source: different version of compile settings
like Visual Studio runtime, used OpenSSL and APR version could produce
different kind of errors.
--
Ivan Zhakov
on\bin\svn.exe (1.9.2.65436, 307200 bytes)
[...]
0x5884 C:\Apache24\bin\libaprutil-1.dll (1.5.4.0, 278528 bytes)
[..]
0x7ff84c5c C:\PHP\ssleay32.dll (1.0.1.13, 364544 bytes)
0x7ff84bc8 C:\PHP\libeay32.dll (1.0.1.13, 1851392 bytes)
]]]
--
Ivan Zhakov
x27;svn log -r 5596 -v file:///data/ans/repos/r4BN' (without log
message) will be also useful.
--
Ivan Zhakov
On 23 November 2015 at 09:52, Thomas Sußebach
wrote:
> please find attached the minidump file
>
>
> Version: 1.8.9 (r1591380), compiled May 8 2014, 13:53:02
Could you please update to the latest version (1.8.14 or 1.9.2) and try again.
--
Ivan Zhakov
seSVN
> 1.9.2), but not with SVN 1.18.14.
>
Could you please provide exact error message that you get? With
filename and other stuff. This would help to find which operation
actually failing.
--
Ivan Zhakov
s that are text files. We already have special
handling for 'image/x-xbitmap' to consider it as text file.
Does it make sense?
--
Ivan Zhakov
On 8 September 2015 at 13:12, Branko Čibej wrote:
> On 07.09.2015 18:42, Ivan Zhakov wrote:
>> We developed patch that converts all ERROR_ACCESS_DENIED errors from
>> SetFileInformationByHandle() to SVN_ERR_UNSUPPORTED_FEATURE and
>> fallbacks to normal close + rename() (se
On 7 September 2015 at 19:45, Ivan Zhakov wrote:
> [Moving to dev@s.a.o]
>
> On 4 September 2015 at 18:15, Daniele Pedroni
> wrote:
>> After updating from 1.8.X to 1.9.X (tried also 1.9.1, no luck), TortoiseSVN
>> as well as command line throw the following error after
e() (see attached file), but I'm not
sure it's the best solution and going to investigate this problem
tomorrow.
--
Ivan Zhakov
Index: subversion/libsvn_subr/io.c
=
e() (see attached file), but I'm not
sure it's the best solution and going to investigate this problem
tomorrow.
--
Ivan Zhakov
Index: subversion/libsvn_subr/io.c
=
On 7 September 2015 at 11:12, Daniele Pedroni
wrote:
> Hi Ivan,
>
> thank you very much, but honestly speaking I don't know how to test it: I
> installed SVN server through Redmine Bitnami package, and I update SVN on my
> PC using TortoiseSVN installer.
> If you prov
didn’t find anything about it.
>
I've attempted to fix this problem in r1701298 [1]. Could you test it?
I may provide development build of Subversion with this fix if needed.
[1] http://svn.apache.org/r1701298
--
Ivan Zhakov
achectl restart' or reasonable equivalent.)
>
The only relevant change in Subversion 1.9.1 compared to 1.9.0 is 1698052 [1]:
[[[
Merge the r1687304 group from trunk:
* r1687304,1687389,1693135,1693138,1693159,1695600,1695606,1695681
Better configure detection of httpd version and auth fix.
Justification:
Build out-of-the box on more platforms.
Votes:
+1: philip, stefan2, brane
]]]
[1] http://svn.apache.org/viewvc?view=revision&revision=1698052
--
Ivan Zhakov
nd may be better
> suited for integrated clients.
>
I think best solution is to move reverted files to Recycle Bin if it
present on platform.
Many platforms seems to have Recycle Bin concept these days: Recycle
Bin on Windows, ~/.Trash on Ubuntu and Trash on Mac OS [1]
[1] http://www.hardcoded.net/articles/send-files-to-trash-on-all-platforms
--
Ivan Zhakov
On 28 April 2015 at 16:15, Benjamin Fritz wrote:
>
> On Apr 28, 2015 8:02 AM, "Ivan Zhakov" wrote:
>>
>>
>> I've fixed at least one problem in svn_stream__install*() on Windows
>> with long path names in r1676526.
>>
>> But I was getting
On 28 April 2015 at 10:07, Ivan Zhakov wrote:
> On 27 April 2015 at 21:35, Benjamin Fritz wrote:
>> Apparently I'm not subscribed to get list emails; please CC me on future
>> responses. I had to get this message from the archive :-)
>>
>> Branko Čibej wrote:
&
le to
>> avoid the path limit ... I wonder what's going on here.
It seems Windows specific implementation of
svn_stream__install_stream() doesn't prepend path with "\\?\" for long
names. Replacing svn_utf__win32_utf8_to_utf16() call with
svn_io__utf8_to_unicode_longpath() should fix the problem, but I
didn't try yet.
Bert, is it intentional behavior or just small typo?
--
Ivan Zhakov
otocol violation. But if github needs more information for fixing this
> please let them contact me.
>
>
Hi Bert,
I didn't look to the code, but is it possible to replace assertion
with some error message for this case?
--
Ivan Zhakov
Removing svn:eol-style (was set to 'native') for files in question
property solved the issue. I guess it's some weird interaction between
Tortoise SVN hosted repository and upstream subversion.
On Mon, Aug 11, 2014 at 11:05 AM, Ivan Drobyshevskyi
wrote:
> There's a st
There's a strange behaviour that is reproduced for some files in our
subversion repository: `touch`ing this file(s) makes `svn diff` show
entire file as changed. Similar happens when opening-saving file in
any text editor or copying it back and forth.
touch:
$ svn status cmVectorStream.h
$ touch c
On 2 July 2014 17:05, Butler, Stephen wrote:
>> -Original Message-
>> From: Ivan Zhakov [mailto:i...@visualsvn.com]
>> Sent: Wednesday, July 02, 2014 14:31
>> To: Butler, Stephen
>> Cc: users@subversion.apache.org
>> Subject: Re: Subversion 1.8 freezes
he network admins, or is there a client/server
> troubleshooting step I've overlooked?
>
> Thanks for any insights,
>
Hi Steve,
1. Does the issue reproduce if you force bulk updates using
'--config-option=servers:global:http-bulk-updates=yes' command line
option or 'SVNAllowBulkUpdates prefer' on the server side?
2. Do you have antivirus installed on client computers?
--
Ivan Zhakov
low in PowerShell.
Also issue can be caused by different disk flush polices on Windows
and Linux: could you try temporary turn off Windows write-cache buffer
flushing on the device:
http://blogs.msdn.com/b/oldnewthing/archive/2013/04/16/10411267.aspx
I do not recommend this as solution, just to find root cause.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
d: VisualSVNServerHooks.exe crashes on commits without 'svn:log' or
'svn:author' properties.
http://www.visualsvn.com/server/download/
--
Ivan Zhakov
<http://www.visualsvn.com>
e observed the behaviour described above on
> Windows 7 using svn 1.7.5, and on Windows 8 using svn 1.8.3.
> There is nothing in the CHANGES file to suggest it's likely
> to have been fixed since then, but I can check with the latest
> release if that's necessary.)
>
ielson/svn/IHSS/trunk
>
>
>
You're using Subversion 1.6.16 which is very old and not supported:
http://subversion.apache.org/docs/release-notes/1.8.html#svn-1.6-deprecation
I recommend you upgrade to latest Subversion 1.8 first.
--
Ivan Zhakov
;
>
As far I remember 'svnadmin hotcopy' doesn't copy uncommitted
transactions. They are stored in db\transactions folder in repository.
You may get several uncommitted and not properly aborted transactions
for long lived repositories.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
I have the same issues but on Windows Server 2008 R2 SP1.
Internal error: Revprop caching for 'E:/csvn/data/repositories/repo/db'
disabled because SHM infrastructure for revprop caching failed to
initialize.
Internal error: -Can't open file
'E:\\csvn\\data\\repositories\\repo\\db\\rev-prop-ato
Two months ago I have upgraded my Subversion Edge from 3.x (1.7.5) to 4.x
(1.8.4) running on Windows Server 2008R2 SP1.
After upgrade all seemes to work fine.
But soon our developers began complaining on a very low commit speed.
After checking log files I have found thousands of identical errors
On 10 December 2013 01:32, Daniel Shahaf wrote:
> Ivan Zhakov wrote on Tue, Dec 10, 2013 at 01:00:32 +0400:
>> On 9 December 2013 21:55, Daniel Shahaf wrote:
>> > Vincent Lefevre wrote on Mon, Dec 09, 2013 at 17:30:21 +0100:
>> >> I noticed that the size of the .
known bug that we need to fix someday.
Btw it's not a bug for some use cases: Subversion doesn't download
files if user switches to branch and then back to trunk. Which is very
useful in some scenarios.
--
Ivan Zhakov
ed patches since
version 2.6.5:
http://www.visualsvn.com/server/download/
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
ned off and see if the issues disappears?
>>
>> I'm not sure if TortoiseSVN is using a ZLib with the assembly
> optimizations
>> enabled, that would probably be something to bring to their lists.
>
> Just checked the source for TortoiseSVN trunk: yes they do use the assembly
> optimizations.
>
> Bert
>
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
#svn-1.6-deprecation
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
On 18 October 2013 18:06, Karol Szkudlarek wrote:
>
> I'm asked about:
>
> " OK. So please tell me whether this fix (r152289) for issue
>> #4425 is already merged to branch 1.8.x?!("
>
> Ivan's answer is not enough for me. Ivan wrote:
>
> &quo
irected to a normal file instead of /dev/null
> which then contains the expected log messages).
>
It seems like issue #4425 [1] which is fixed in r1522892 and proposed
for backport to Subversion
1.8.4.
[1] http://subversion.tigris.org/issues/show_bug.cgi?id=4425
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
On 4 October 2013 17:00, Karol Szkudlarek wrote:
> W dniu 2013-10-04 14:50, Ivan Zhakov pisze:
>
>> On 4 October 2013 16:44, Ivan Zhakov wrote:
>>>>
>>>> I'm trying to use the latest 1.8.3 64-bit version of svn client:
>>>>
>>>>
On 4 October 2013 16:44, Ivan Zhakov wrote:
>> I'm trying to use the latest 1.8.3 64-bit version of svn client:
>>
>> CollabNetSubversion-client-1.8.3-1-x64.exe
>>
>> but several times crashes. In attachement are log and dmp.
> Hi,
>
> The attach
le to investigate the issue. I recommend you contact company
produced this binaries (CollabNet) or try to reproduce problem with
other Subversion binaries distribution and contact them.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
On 30 September 2013 17:42, Kesavan Sengodan
wrote:
> Dear Ivan Zhakov,
>
> The solution URL has only the source code. Compiling it is big task.
> Is there any binary available for this solution?
> If yes, where can we get it? Kindly help us.
>
VisualSVN Server has these f
nown problem in Apache HTTP Server 2.2.25:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55397
The only known solution is to revert these buggy changes in Apache HTTP Server:
http://svn.haxx.se/dev/archive-2013-08/0479.shtml
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
al/trunk/confi:4217,4378,4459
> Missing ranges: /portal/trunk/config:4387,4435,4452
Hi, Andrew.
Could you check value of svn:mergeinfo properties on /portal/trunk and
/portal/trunk/config in repository AND working copy to identify where
merge info was corrupted. Thanks!
--
Ivan Zhakov
rashed.
>
> Same crash for
> svn.exe log | more
>
Filed as issue #4425:
http://subversion.tigris.org/issues/show_bug.cgi?id=4425
Simple fix is coming soon.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
On Fri, Sep 13, 2013 at 3:43 PM, Ivan Zhakov wrote:
> On Thu, Sep 12, 2013 at 10:53 AM, Sergey Azarkevich
> wrote:
>>
>> Reproduced on:
>>
>> svn, version 1.8.4-dev (under development)
>>compiled Aug 23 2013, 17:30:38 on x86-microsoft-window
gt;> C:\SomeDir\Project (which is the root of the working copy), and you
>> execute "subst M: C:\SomeDir\Project"? If so, that works fine (just
>> tried it with 1.7 and 1.8).
>>
>> But if you want "subst M: C:\SomeDir\Project\subdir", tha
ase so you get CN mistmatch if
you have uppercase letters in your server certificate. This problem
should be fixed in upcoming Subversion 1.8.3:
* ra_serf: ignore case when checking certificate common names (r1514763)
Is it your case?
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
On Wed, Aug 21, 2013 at 12:01 PM, Ben Reser wrote:
> On Wed Aug 21 00:17:08 2013, Ivan Zhakov wrote:
>> The first bug here why Subversion 1.8 doesn't ask you for credentials on
>> checkout
>> like it does for commit.
>
> Known limitation of HTTP, see the Partial
On Wed, Aug 21, 2013 at 4:17 AM, Mark Tsuchida wrote:
> Hi Ivan,
>
> On Tue, Aug 20, 2013 at 12:02 AM, Ivan Zhakov wrote:
>> On Mon, Aug 19, 2013 at 11:14 PM, Ivan Zhakov wrote:
>>> On Mon, Aug 19, 2013 at 10:19 PM, Mark Tsuchida
>>> wrote:
> [...]
&
On Tue, Aug 20, 2013 at 2:05 PM, wrote:
> On Tuesday, August 20, 2013 10:47:22 AM UTC+2, Ivan Zhakov wrote:
>>>
>>> On Tue, Aug 20, 2013 at 12:20 PM, wrote:
>>> > On Monday, August 19, 2013 5:41:55 PM UTC+2, Dinesh Hirani wrote:
>>> >>
>
abNet then restarts another instance.
>
> Is it something you'd like to share?
>
> I used ProcDump to create a dump when the process went to 100%. Would it be
> usefull to post it here?
>
Could you post just call stack here?
--
Ivan Zhakov
On Mon, Aug 19, 2013 at 11:14 PM, Ivan Zhakov wrote:
> On Mon, Aug 19, 2013 at 10:19 PM, Mark Tsuchida
> wrote:
>> Hello,
>>
>> I'm having an issue with our partially-public SVN repository.
>>
>> The server is running SVN 1.6.11 (CentOS 6.4) with Apache
unds like it's not fixed in 1.8, but possibly fixed in trunk
> (i.e. the future 1.9 version).
>
> I'm not sure if this bugfix is at all backportable to 1.8, or if
> you'll have to wait for 1.9. Maybe someone else can comment
> (otherwise: go ahead and ask the "can i
client 1.6.18 only ever requests
> /svn/myrepo/!svn/bc/123/trunk, to which access is granted.
>
Most likely it is some problem with inherited properties feature
implemented in Subversion 1.8.
@Paul: Do you have any ideas?
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
ication window when it tries to get
list of repositories using Windows API, not Subversion libraries.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
On Sun, Aug 11, 2013 at 8:54 PM, Ben Reser wrote:
> On Sun, Aug 11, 2013 at 3:24 AM, Johan Corveleyn wrote:
>> I'm cc'ing Ben Reser (who has the above issue assigned to him) and
>> Ivan Zhakov (who recenty wrote a patch for this). Perhaps they can
>> shed some li
This is definitely serf issue 77. Issue should be fixed in r2112. And
most likely will be backported to next serf 1.3.x release.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
[[
ra_serf: Do not retry HTTP requests if we started to parse them. There is
absolutely no guarantee that REPORT or PROPFIND responses will be equal for
every request. Especially with taking to account hash randomization.
]]]
Revision is nominated for backport and should be available in Subversion 1.8.2.
[1] http://svn.apache.org/r1503318
--
Ivan Zhakov
NGES
>
Reading symbolic links on Windows Vista and later is implemented on
trunk in r1501251 [1]:
[[[
Implement reading symbolic links on Windows Vista or later. This fix
issues with working copies located in symlinked folders.
]]]
Maybe it worth to backport this change to 1.8.x
's not allowed to call apr_initialize() more than once per process.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Hello,
Here I send you a crash report in SVN.
This crash occurs when Redmine (project management application)
tries to fetch revisions for SVN repositories.
--
Regards,
Ivan Cenov
OKTO-7 Co. Bulgaria
i...@okto7.com, i_ce...@botevgrad.com
mobile:+359888761080,
phone:+35972366161, fax
_new.svndump
>
[...]
>
> Do you have an idea?
>
Could you please try to run svnadmin command with memory caching disabled. I.e.
E:\VoloxTmp>"C:\Program Files\VisualSVN Server\bin\svnadmin" dump -r
19000:29950 -M 0 E:\svn_repository_new > E:\VoloxTmp\dump_new.svndump
--
Ivan Zhakov
On Mon, Nov 14, 2011 at 18:21, Waseem Shahzad wrote:
> I need to download SVN 1.7.1 Server for windows. Any link.
>
http://www.visualsvn.com/downloads/
--
Ivan Zhakov
Replace a decade-old TODO about checking authorization on
a directory's children with, you know, code that checks
authorization on a directory's children.
]]]
--
Ivan Zhakov
On Tue, Jul 26, 2011 at 20:45, Ivan Zhakov wrote:
> On Tue, Jul 26, 2011 at 20:25, Ivan Zhakov wrote:
>> On Tue, Jul 26, 2011 at 13:37, Becker, Thomas
>> wrote:
>>> Yes, actually starts with svn. The URL looks like this:
>>> https://:8443/svn/
>>
On Tue, Jul 26, 2011 at 20:25, Ivan Zhakov wrote:
> On Tue, Jul 26, 2011 at 13:37, Becker, Thomas wrote:
>> Yes, actually starts with svn. The URL looks like this:
>> https://:8443/svn/
>>
>> Regards,
>> Thomas
>>
> Could you please try to add exp
d-custom.conf" file and
restart the server:
ServerName :8443
--
Ivan Zhakov
gt;
The URL for VisualSVN Server repositories should be like
https:/xxx:8443/svn/yyyy. Please make sure that you are using correct
URL to repository.
--
Ivan Zhakov
hi
i have upgraded my subversion to 1.6.15 version, but, have various
problems with this.
when i commit a project, this error is reporting
Morpheus-MacBook:teste ivan$ svn commit .htaccess --message teste
Sending.htaccess
Transmitting file data .svn: Commit failed (details follow):
svn
of the repo where
affected,
i can commit new files to some paths of the repo, but i can`checkout,
commit on other, the repo is about 130GB so dumping and filtering the
revisions
at least today is not an option.
Someone please help with ideas on how to fix this.
Att.
Ivan Fernandez
;s mistakes but nothing can save you from this.
Back to my original question - shouldn't ".svn" administrative
directories be inaccessible by "others"? Just like OpenSSH requires that
its per-user config directory ~/.ssh is writable only by its owner and
nobody else.
Cheers.
--Iva
R_OS_DEFAULT, pool);
+ /* Protect the administrative subdir from being accessible by
"others". */
+ return svn_io_dir_make_hidden(path, (APR_OS_DEFAULT & ~(APR_WEXECUTE
| APR_WWRITE | APR_WREAD)), pool);
}
Please let me know what you think. Should I direct this to the "dev"
mailing list? Thanks.
Best regards,
Ivan Zahariev
89 matches
Mail list logo
