On 15.04.2015 3:09, Trevor Saunders wrote: > On Tue, Apr 14, 2015 at 10:46:19AM +0200, Richard Biener wrote: >> I see no value in doing this but making branch maintainance awkward. > > I think its mostly valuable to cause less confusion of new people, and > though it is a simpler thing every little thing can be the thing that > breaks the cammel's back. Yes its not all that hard to configure > editors and what not to handle it properly, but every new person needs > to do it, and looking up configuration options takes time that can more > profitably be spent. Well, for me, as a newcomer, configuring the editor and getting used to non-standard file extensions was, perhaps, one of the easiest parts (but yes, that's a bit confusing).
You mentioned that you are planning to do reorganization of the directory structure. That would be really helpful. LLVM has two separate directories for utility classes, functions and custom datatypes (llvm/include/llvm/ADT and llvm/include/llvm/Support). In GCC all those useful things are scattered among 771 files in gcc directory, some are in libiberty. There is no need to wait for reorganization to at least create a list of such support data structures and functions (something like this: http://llvm.org/docs/ProgrammersManual.html). The good thing is that we already have excellent documentation for some of them in source code (for example vec.h and is-a.h), but we are missing the list. > > That said keeping backports as easy as possible is also certainly > important. I'm curious why renames hurt doing backports, I'm pretty > confident git cherry-pick will handle it for you, and if you like patch > files for some reason I'd think its easy to fix up with sed though > running that for each backport by hand would get a little old. > IIRC, SVN can dump the whole repository and import it again. So, if it's really desired, it's possible to rename the files "in the past" without loosing the history by filtering the dump (but git mirror must be rebuilt in this case). -- Regards, Mikhail Maltsev
