Beman Dawes wrote:
Boost developers and release managers, OTOH, don't ever do project wide merges. Instead, everything happens on a library by library basis. I would expect merging a single library would be easier if its header files lived entirely within the library's boost-root/libs/libname tree.
Having libraries organized with nearby headers may be a better organization scheme and make some operations easier: agreed, we'll try it out. I'll maintain that whether or not to put these perhaps-better-organized directories on the ends of svn:externals is a different issue with long term consequences.
Right now boost developers and release managers do single project switches; (modulo those who go to the trouble of using svnmerge.)
Didn't svnmerge become obsolete when Subversion added merge tracking?
I don't think the server was upgraded.
Naturally that isn't an argument _for_ locking in to a path that excludes the possibility of bonafide merges, assuming there is some alternative. This would be a bit like (hypothetical) deciding on a path that somehow restricted us to using fixed size containers, just because we're getting by without them right now.
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.
As I've pointed to on IRC already, merge tracking in SVN 1.5 is in some aspects more powerful than in git. So maybe it's best, indeed, to stop mixing version control system discussion with an otherwise tricky topic.
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?
From IRC discussion, it seems that Troy and I had different use of svn:externals in mind. I assumed that
trunk/boost has svn:externals for each headers directory, e.g. filesystem ../libs/filesystem/headers Therefore upon checkout, you get a complete copy of all headers in 'boost' dir. This arrangement does not create any problems for branching or merging whatsoever. What Troy had in mind (according to my understanding, which may be faulty), is that svn:externals are used on trunk/libs and pull libraries from some other location. This will indeed create additional inconvenience for merges, but it's not clear why this arrangement is desired. - Volodya