Hi,
sry for the belated answer. It took me a while before I had some time to
investigate that issue deeper.
Following investigations were done with TSVN 1.8.5 (Subversion 1.8.8)
and Server is now running Visual SVN 2.7.3 (based on SVN 1.8.5).
I traced the issue down to obvious problems wit
Hi,
I also think I found a (to the other described problem most likely
distinct) issue.
The problem occurs in a file deep in the folder structure.
Let's say it' occurs with a file located in :
Repo/trunk/A/B/C/D/E/filename.exe
When I check-out trunk let's say on G:\test and do an update on t
Hi,
It would have also been quite useful to get the filename of that file
that SVN tried to copy the temporary for. If it would have stated
"print_options.exe", we could have run a bit of testing just with that
one file to easier trace it down to an anti virus related problem
(would have been
Hi,
I came up with an even easier repro case. It seems to suffice to trigger
the problem by simply committing the problematic file to an empty local
repository and having avast installed.
To whom should I send the repro-case (it requires the zipped-exe-file).
Regards,
Stefan
Hi,
sry for the
On Wed, 26 Feb 2014 20:41:38 +0100
Henrik Carlqvist wrote:
> Now I have finally been able to create a small case where merge
> information is lost.
I didn't get much response here, do you think that I should file a bug
report into the subversion issue tracker?
regards Henrik
On 2014-03-02 11:40, Stefan wrote:
> Hi,
>
> I came up with an even easier repro case. It seems to suffice to trigger the
> problem by simply committing the problematic file to an empty local
> repository and having avast installed.
> To whom should I send the repro-case (it requires the zipped-
On 02.03.2014 11:40, Stefan wrote:
> Hi,
>
> I came up with an even easier repro case. It seems to suffice to
> trigger the problem by simply committing the problematic file to an
> empty local repository and having avast installed.
> To whom should I send the repro-case (it requires the zipped-exe
Hi Brane and Olli,
On 02.03.2014 11:40, Stefan wrote:
Hi,
I came up with an even easier repro case. It seems to suffice to
trigger the problem by simply committing the problematic file to an
empty local repository and having avast installed.
To whom should I send the repro-case (it requires
Guten Tag Stefan,
am Sonntag, 2. März 2014 um 20:23 schrieben Sie:
> Well, if you are sure that the virusscanner is actually causing the
> rename, of course there's little SVN could do about. But then I'd
> find that really odd for a virus scanner[...]
Wouldn't be the first "odd" thing about s
On 02.03.2014 20:23, Stefan wrote:
> Hi Brane and Olli,
>> On 02.03.2014 11:40, Stefan wrote:
>>> Hi,
>>>
>>> I came up with an even easier repro case. It seems to suffice to
>>> trigger the problem by simply committing the problematic file to an
>>> empty local repository and having avast installe
Hi Thorsten,
and wouldn't suspect that it is doing that.
Is there some code path I'd trace down to confirm it's actually the
virusscanner causing the rename? Where in the code path would thetmp-file
be generated?
I would first try to use Process Monitor to see activity in the file
system,
Hi Brane,
Is there some code path I'd trace down to confirm it's actually the
virusscanner causing the rename? Where in the code path would the
tmp-file be generated?
The call stack is probably:
svn_io_open_unique_file3
svn_stream_open_unique
svn_wc__open_writable_base
On 02.03.2014 22:54, Stefan wrote:
> Hi Brane,
>>
>>> Is there some code path I'd trace down to confirm it's actually the
>>> virusscanner causing the rename? Where in the code path would the
>>> tmp-file be generated?
>> The call stack is probably:
>> svn_io_open_unique_file3
>> svn_stream
I recently upgraded from 1.8.5 to 1.8.8 via macports. The new version
refused to permanently accept my self-signed certificate, citing an
"unknown error".
Certificates generated on Windows 2008 Server using VisualSVN 2.7.4.
Hostname is a numeric IP on a VPN (192.168.100.59)
Client is Mac OS X
Hi Brane,
Is there some code path I'd trace down to confirm it's actually the
virusscanner causing the rename? Where in the code path would the
tmp-file be generated?
The call stack is probably:
svn_io_open_unique_file3
svn_stream_open_unique
svn_wc__open_writable_base
15 matches
Mail list logo
