Jason Winnebeck <[EMAIL PROTECTED]> wrote: > Maybe it does something silly like assume sizeof(int) = 4 bytes? I don't know, > on modern compilers was the decision made that int should become 8 bytes (64 > bits wide)? I know that size of pointers would have to change, but if it is > trying to do IO based on pointer sizes that would be really out there. > > Jason > > David Blaikie wrote: > > my mistake - ssphys has the problem... > > > > On Nov 30, 2007 4:15 PM, David Blaikie <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > eek. This is the same error I was going to bring up next - the > > error I got when migrating a small database! Looks like I'm out of > > luck, then! > > > > Anyone have any idea why this should be so? Why should vss2svn have > > trouble on 64? > > > > David
I actually ran into this problem a while ago and never remembered to post my solution. It's pretty much as you say--in SSTypes.h, unsigned longs are being used as members in some structs, breaking things, due to the assumption that they'll be 32-bits wide. I just changed the typedef for "ulong" at the top of the file to be an unsigned int, recompiled, and it worked fine. Erik _______________________________________________ vss2svn-users mailing list Project homepage: http://www.pumacode.org/projects/vss2svn/ Subscribe/Unsubscribe/Admin: http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org Mailing list web interface (with searchable archives): http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
