On Thu, Jun 21, 2012 at 11:40 AM, Paul Harris <harris.pc@xxxxxxxxx> wrote:
>
>
> On 20 June 2012 14:57, Pascal Obry <pascal@xxxxxxxx> wrote:
>>
>> Jon,
>>
>> > Thank you. I think we have tried the -b option without much luck, but
>> > I don't think we have tried the -o option.
>> >
>> > I will arrange to do some testing and will post to the list in a few
>> > weeks if this looks to be a definitive solution to the problem (or
>> > otherwise)
>>
>> Ok, the most important part is running peflagsall, this was the way to
>> fix that properly on Win7 IIRC.
>>
>> Pascal.
>>
>
> Hello,
>
> I use git + cygwin on Win7-64 (almost) without problems. I have used
> git-svn too (once) with success.
We do use git svn fairly heavily as part of our normal workflow and it
is git-svn that is most heavily affected by the issue. If you only use
git-svn occasionally, it is possible that you have avoided the
particular issue we are facing. For us, git-svn does tend to work
immediately after the rebase or after a fresh boot when not much is
loaded, but the reliability will be tend to degrade over time,
presumably as the 32bit address space becomes more "polluted" by the
other demands placed upon it.
>
> Perhaps Jon's is not working because rebaseall is not rebasing the
> particular binaries he is using? Perhaps his git svn is running some
> binaries/dlls that are installed in non-standard locations? Can that
> happen?
I don't think this is the case. All the users affected have a pretty
standard scripted cygwin install - there are no variations between
users and no special considerations for the SVN installation. We tried
some of the suggestions we found here about explicitly enumerating all
the .so and .dll files
http://stackoverflow.com/questions/4988091/unable-to-start-solr-server-ruby-on-rails/6601464#6601464
but this didn't change the behaviour.
I suspect the flavour of anti-virus solution one has installed may be
a factor. We are using Norton Antivirus.
Another factor might be the other tools we are running (Java IDEs and
application servers) although I haven't seen any good evidence one way
or the other about whether the JVMs are actually a factor. As
mentioned above, It does seem true that time since reboot is a factor,
which is presumably related to how the 32bit address space is
"fragmented" over time by the various demands placed on it.
Thus far, Pascal's solution seems to be working, but it is a bit early
to call it a success yet - we will need several more days testing to
be sure.
jon.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html