[Box Backup-dev] 07-win32-fixes

[Jonathan Morton]

>> >   But copying is free (on the server) and making a copy is supposed to be 
>> >   a standard (only?) way of creating a tag or branch with SVN, as far as 
>> >   I know. I don't think you're supposed to check out the whole repository 
>> >   :-).
>>
>>  Whether you're supposed to do it or not, people do.  Especially the people
>>  who are supposed to merge it all.
>
> I never asked anybody to merge every single branch I ever made :-) But I'm 
> quite happy to delete the old tags now that I don't need them anymore. I'm 
> also quite happy to do the merging if people want me to (and I promise not to 
> check out the entire repository :-)



>>  Most of the problem seems to be that the Win32 port branch contains an
>>  entire copy of the Boost library for each sub-branch - presumably only the
>>  XML features of Boost were actually required, and in any case Boost should
>>  be installed separately from the application on a developer's machine.
>>  Boost itself is not modified for use in BB, so why include it in version
>>  control?
>
> I didn't check in Boost, and it was one of the first things that Martin and I 
> removed from our working copies. It's only there in the old, obsolete 
> branches (some belonging to other people, that I didn't want to touch).

Fair enough - and I saw that just now when I updated my copy of the tree. 
It was still worth noting for others.

>>  "Much harder" should not be confused with "not familiar".  It is quite
>>  easy to retrieve the commit log for any given directory, and produce an
>>  individual diff covering each individually or any combination.
>
> Well, it's not how I was taught to use SVN by the book. But I'm happy to do 
> it that way if people prefer.

As with many other things, "the book" is not always right.  I think 
there's a distinction to be made between chronological refinements and 
lines of enquiry.  The latter case is an appropriate time to make 
branches.  The former is not, because SVN's internal systems already take 
care of it much more efficiently.

I suppose the ambiguity came in when you have a big patch, like the Win32 
stuff, that needs to be merged, but not all of the changes are appropriate 
for merging.  The patch can be split into sections as normal, but I think 
these sections should be applied and committed sequentially to a single 
tree - or at most to two parallel trees (one for review and 
experimentation, the other for finalisation).

Partial changes can be backed out at any time with minimal fuss, as long 
as you can work out the revision numbers from the commit log (which you 
should be able to do anyway for merging).  Making half a dozen 
closely-related branches, one for each patch fragment, doesn't seem 
appropriate.  Instead, apply each patch fragment in turn to the single 
tree, weeding out the inappropriate ones as you find them.

This would at least have reduced the impact of the Boost incursion.  :-)