If we do move things around in trunk, will it make merging changes
made in the 1.1 branch more difficult?
Most likely... not sure how well SVN tracks changes and then merges
back from branches after bits have been moved about.
<soapbox>
I know that Perforce would be able to handle these types of merges...
</soapbox>
Basically it will mean that files will need to be merged one by one
explicitly, not using the recursive mechanism.
If so, how important is it to move things now and would there be a
better time to do it, e.g. when 1.1.1 is released?
Well, I believe it is important... moderately important. We
eventually need to bite the bullet and make these changes, which will
cause some additional work when merging due to the way that SVN
works. It is work that must be done at some time, and I think that
the sooner the better.
Its not just the organization of the module's files... but also the
organization of the modules themselves. IMO we MUST do both to take
the most advantage out of the new m2 build system.
I can't stress enough that the current layout was designed around
m1. m2 is quite different with respect to the rules that apply when
organizing.
I'm not sure that delaying these changes will making anything
easier. It may reduce work by 5-10% in the short-term but will
probably increase work in the long run if we keep delaying to keep
merges simple. If we really want to keep merges simple, then we
should use Perforce, which actually handles incremental merging and
can handle any arbitrary branching and handle full integration
history when merging back off of branches of branches. Sorry, back
on the soapbox again... but really IMo there is no better SCM than
Perforce for large projects that need advanced branching and merging.
--jason
