Stefan Küng <firstname.lastname@example.org> wrote:
> Instead of changing the code in various places, can't we just use a
> define like this:
> #define WIN32 _WIN32
That *might* work if you find some central place in the C projects
to do that. However, one can easily imagine situations where they
want to distinguish between WIN32 and WIN64. Anyway, this
has to be discussed by the respective project owners (no such code
> But this would be against the C-standard? Isn't there maybe a switch in
> the compiler settings to turn this 'compatibility mode' off?
Nope. The special problem is sizeof (size_t) > sizeof (long). Thus,
pointer casts between them are EVIL.
> Or, once I have VS2005 myself we could just get rid of the 'unsafe'
> functions ;)
That would be nice. Since TSVN is bound to Win32 anyway, there is
no compelling reason to stick with the std C functions.
> Well, since VS2005 isn't out yet, they can't really test this. I think
> they'll fix that soon.
Of course. It had already been begun in the .py scripts. It just isn't
> I saw that you removed a check in GRETA which would refuse compiling if
> that's not the case anymore. Is that safe to do?
Nope. That's a remnant of my experiments. As a result, the only
way to get that fixed to switch to restring instead of TCHAR*.
It will be cleaner code anyway.
> what are parallel builds?
If project dependencies allow, independent projects within a solution
will be build simultaneously. On my 2x248 this is fun to watch.
> I got this mail, read your 'done' and wondered if you forgot to attach
> the patches. Then I went to the website, searched the mailing list
> archive and there it was! Seems GMail didn't like your mail - I haven't
> received it. Anyway, I got your patch from the archive. Thanks!
Hm. Send and receive order seem to get mixed up. Some posts
take a very long time (8 hours?) to get archived. I even see delivery
failures from time to time.
> No problem. Until now, there are very few people in need of a 64-bit
> version. And those who do still can use the 32-bit version of the
> explorer if they really want to use TSVN.
Perhaps, in a more realistic scenario there will be only a TSVN64.dll
for shell integration, leaving everything else 32 bit. So, there won't
be a need to have completely separated installation etc.
> So for now, I can't apply your patch because it breaks my build (well
> not my build, but my ability to run TortoiseSVN).
I'm sorry that I haven't stated that more explicit: The large ZIP file
was never meant to go to /trunk. Instead, it should linger in some
"dark" corner of the repository where people may download and
The "prime-time ready" patches have just been extracted. The ones
belonging to TSVN have been posted a few minutes ago (2 bounced
back - I will check them).
So let's see what those patches do to TSVN ;)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Aug 19 20:03:22 2005