[Box Backup-dev] 07-win32-fixes

[Martin Ebourne]

Chris Wilson <chris at qwirx.com> wrote:
> Hi Ben,
>> Would Martin like to give it a sanity check and merge it in? (seeing 
>> as Martin has somehow ended up as the project merger...)

I'm still not sure why I'm project merger, and I'm not all that keen to 
keep the position! I've ended up being the release manager at work as 
well, and I don't want that position either!

> That would be great! :-) Martin, please let me know when you are 
> done, and I'll take a cut from your new trunk.

I've had another look over the diffs:

In BackupClientFileAttributes::ReadAttributes there is a new section of 
code which says "this is to catch those problems with invalid time 
stamps stored". Is this a windows only problem, or could this happen 
also on Unix? Should the check be cross platform?

I would like to try to remove most of the WIN32 uses by having proper 
feature tests in configure.ac rather than using the platform define. 
There are several which are type based, eg. in BoxPlatform.h:

    typedef __int8  int8_t;
    typedef __int16 int16_t;
    typedef __int32 int32_t;
    typedef __int64 int64_t;

and

    typedef ino_t InodeRefType;

These could all be using the type checking macro in configure.ac. Also 
there are a lot of #includes conditional on WIN32 where really they 
should be conditional on the include itself. Between those two it would 
reduce a lot.

Later on we can try and do the same for the conditional code sections. 
In a couple of cases I think we can make them more generic and remove 
conditionality.

I'm happy to merge as is and fix this up later, but will need Chris's 
help for this.

I'm planning to merge with the following command:

    svn merge -r111:187 chris/win32/merge/08-file-renames trunk

This should be the same as the diff between 
00-martins-original-autoconf and 08-file-renames. I've done a test 
merge and it is conflict free.

I'd also like to request that in future we don't proliferate so many 
branches. I checked out a working copy of the whole repository and it 
takes 2.5GB of disk! That is split as:

24M     ben
24M     chromi
27M     trunk
109M    martin
592M    nick
1.8G    chris

We want to make big changes on a branch, and occasionally it is useful 
to create a new branch, but I don't think it helps to create a new 
branch for each cumulative change to a tree. In SVN each checkin is 
referred to by a single number so unlike CVS it is always easy to 
cherry pick complete changes out of the history. With a suitable log 
comment each point in time is just as accessible on a single branch 
line as it is by branching at each stage.

It would probably help to remove some of the branches after the dust 
has settled. They wouldn't be lost of course, just no longer in the 
latest version.

Cheers,

Martin.