Beman Dawes wrote:
I find "bona fide merges" and similar terms somewhat offensive. People are always claiming this or that source control system doesn't do "bona fide merges". Well, even the really crappy systems handle at least some merge scenarios without problems. Is there any SCS that handles all possible merge scenarios? I doubt it.
What is the specific merge scenario that you are concerned about? Does the concern still apply to SVN 1.5 and later?
How about: Branch A: the trunk @ HEAD. Branch B: the trunk 100 commits ago, with fixes and patches sprinkled all over it, and a couple of proposed libraries added. If there are no conflicts the merge happens in ~5 seconds or less.
Note that under the svn:externals scheme, one not only can't do a wide
merge,
Could you explain what you mean by "wide merge"?
(as above)
one can't even wide-branch easily. You must:
- branch the toplevel project (a commit) - foreach project that you want to modify - branch it (a commit)
- change your externals and commit
I'm trying to understand why this would be necessary. For a given library, what directory has the svn:externals property? What does the svn:externals property entry look like for a given library? Why do the externals have to be changed? Is the root problem that the svn:externals property has to be attached to a directory above the library's boost-root/libs/libname page because svn:externals properties targets don't support ".." in their paths?
The externals: libs/serialization http://svn.boost.org/svn/boost/projects/serialization/trunk libs/flyweight http://svn.boost.org/svn/boost/projects/flyweight/trunk Of course I've just argued that you don't want to do this, but the reason you would is to be able to create subdistributions of boost and version components independently of one another. This doesn't take care of constructing your single include/ directory.
What might an optimal solution to keeping headers in their library tree look like that didn't use svn:externals? Perhaps something like this:
* For users (i.e. anyone needing read-only access), a post-checkout step that moved the headers from their library tree to boost-root/boost.
* For developers (i.e. anyone needing read/write access), a post-checkout step that created hard links in boost-root/boost.
Something to think about if svn:externals can't be made to work.
Well there is the approach that Qt has been using for many years, which Juergen pointed out. I coded up a prototype, see mails in this thread with 'qtsync' in the subject. -troy