Hans-Emil Skogh [mailto:Hans-Emil.Skogh_at_tritech.se] wrote:
>>>>> I tried to commit a single file in a working copy using the latest
>>>>> nightly. (WC on a network share, repo via svn://.) Thi s ended up
>>>>> hanging the committing TortoiseProc.exe instance, somewhere around
>>>>> "sending data", with 100% processor usage.
>> Did it first fail with last Wednesday's build or already before that?
>Both failed in the same way.
That disproves my theory. The /MP switch got set
>> I observed a similar issue with last Friday's nightly.
>> In *that* build, the diff was broken in some cases (e.g. generating
>> certain uni-diffs between log entries).
> How did this manifest itself? Failed commits or successful commits of broken data?
Mainly in the log dialog: select two revisions and
display the unified diff. This had often resulted in
a hanging TortoiseProc process. One time, a commit
displayed the same behavior during the "sending"
>> The code spun over a short sequence of machine instructions that were
>> r/o, i.e. the that loop would never be exited.
> Could be the same thing that I saw. Sounds just like it.
It probably is.
>> From the looks of it, this seems to
>> be a compiler bug - possibly caused by the "doubly"
>> concurrent build of the sln. I kind of remember to have seen some post
>> about that somewhere but could not find it again.
>:-/ Any idea on how to avoid it?
I talked to some people in-house and they told me
that the build itself could fail due to the /MP setting
but the binary output should not be corrupted. In
combination with the fact that it already failed before
the change, something else it to blame. I won't find
the time to look into that before the WE, though.
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-03-01 14:46:30 CET