| Re: [imp-dev] Proposed reorg of IMP SVN repository structure |
| Hi Jurgen, As for (1), as far as I can tell, all of the other SVN-hosted projects I've seen so far use the proposed new structure. It's partly this observation that motivated the proposal. Also, several other more experienced SVN users have commented that the current organization is a pain. Newcomers have been pretty consistently surprised by the organization. That said, I personally don't have that much SVN experience outside this project, so if you can offer more *details* about how the current structure eases modular development (and also how the proposed structure would make it more difficult), we'll have more to go on in making the decision. Regarding (2), all projects are already being tagged for each release. So far, each plugin project has been tagged with the plugin's version, though tagging it with the feature version is also reasonable (but I haven't been doing that yet). For that matter, we're essentially already releasing parts of IMP independently. By that I mean that although the complete set of features happen to live at the same update site, they are not coupled in any significant way, beyond their explicitly stated feature dependencies. Also, a feature had better contain a consistent set of plugins, and arranging for them to have either the same tag, or at least a tag derived from the plugin's version for that version of the feature, seems more or less mandatory (for traceability, if not for build and debug ease). We can just as easily branch Moreover, the "big blob" problem is one that *must* be addressed at the level of plugin and feature dependencies, which we maintain carefully for that precise reason. No amount of trickery at the level of repository organization will avoid that. In fact, the current repository structure does nothing to avoid that problem. In short, I don't see how the current organization does anything but cause inconvenience for both naive use and the sort of more sophisticated use you've mentioned, insofar as I think I understand what you're alluding to. That said, something in the middle (organizing by features) might make more sense, but would (as far as I can tell) flout convention altogether. Finally, if past experience is any indication, we're unlikely to see requested enhancements of the Team tooling any time soon, so I'd rather not wait for that to solve the ease-of-use problem we've been facing since we first set up the repository. The problem I see with Team Project Sets is that (1) they need to be maintained, and there's no tooling to do that (outside the IMP RelEng tools, which I've had a hard time finding time to maintain) and (2) no matter what one does to make the project sets visible, few people know/remember about them. So particularly given (2), we need a simple scenario that doesn't depend on them. [FWIW, we do/did have one on either IMP's web page or Wiki pages, but I don't know at the moment what the status is.] On Apr 10, 2009, at 2:47 AM, Jurgen Vinju wrote: Hi, -- Cheers, - Bob ------------------------------------------------- Robert M. Fuhrer Research Staff Member Programming Technologies Dept. IBM T.J. Watson Research Center IMP Project Lead (http://www.eclipse.org/imp) X10: Productivity for High-Performance Parallel Programming (http://x10.sf.net) |