Hi Frank, Frank Schönheit - Sun Microsystems Germany wrote: > Hi Heiner, > >> Well, this +1 or -1 one in s a kind of vote and you normally don't have >> to explain your votes. Note that I didn't say "We will not do this, I'm >> the maintainer of this stuff, basta!" :-) Just a vote. > > Ah, okay ;) > >> These are roughly 50 platforms times 191 top level dirs, about 9550 >> entries to maintain. That I call clumsy. Since most of the platforms are >> only interesting to a few people I feel that having this in the so >> called global ignore list might not be unreasonable. > > (Didn't know we have that much platforms ...)
That's why an ignore property on each directory will always be, well, incomplete. > > Well, every time we switch to a new compiler on a new platform (which > happened quite some times in the younger past), every developer working > on the respective platform has to adjust the global ignore list in his > Unix Home, and in $(APPDATA)\Subversion on each and every Windows > machine he's regularly using. Just vary the wildcard pattern a bit, say: common common.pro unxsol* wntmsci* unxlng* unxmac* ... and you are save for the next 10 years or so. It's a glob pattern after all. And you don't need it for platforms you don't build. > > Multiplying all those developers with all those profiles probably does > not sum up to 50*191, but in opposite to maintaining the SVN property > (which can be done by simple scripts), maintaining the config files is > manual work. > > So, I still think putting the stuff into SVN is better ... (Hey, what > did we do the migration for if we don't use all the cool new SVN features?) > ... at least for the *most common* platforms - what the *#+%&$# is > "unxhpxr"? And how many people will ever encounter it in real life, > compared with unxlngi6, unxmacxi, and wntmsci12? I guess OpenOffice.org on HP-UX on a MIPS architecture. And, no I will not discriminate against less known platforms, so a partial list can't be an option. :-) > >> As for "I can't use the platform names in the ignore list readily": Well >> this is a good(TM) thing. You should not use this names, they are >> reserved for the build process. > > Well, yes, sure. > > Except that the ignore list you suggested in the Wiki also excludes > files like "common_data.txt" ... OK, using "common*" in the global ignore list is going to work for me, but I changed the example to spell out "common" "common.pro" explicitly. If you still want to add a file named "common", do it with "svn add common". Files like "common_data.txt" will not fall under the changed global ignore list. > > Also, the reservation of those names only is true for the module root > folders (i.e. the location where the "prj" sub folder resides), not for > other locations. > At least this would be my understanding, though you could say that the > names are (by definition) reserved globally, and I'd easily accept that. The platform names never make a good file name except in a very few cases. Better stay away from them. And I think that we agree that "common" and "common.pro" aren't great file names and better should not be used as directory names either. > >> If you insist on using them, well there >> is always the "--no-ignore" switch to svn add, or you just explicitly >> add a path with this name. Once a path is under version control the >> ignore list has no effects anyway. > > I know (I meanwhile read the FM :) - I intentionally wrote "makes it > difficult", not "makes it impossible". I do not really think that adding a path explicit with "svn add <path>" is very difficult. It just insures against doing it accidentally by a recursive add, just as it should be :-) Well, you probably already noticed that I'm somehow not very enthusiastic about maintaining these 10000 entries. Remember, you'll have to add the properties every time someone invents a new top level directory, which means with most milestones. And you have to change all 200 of them if someone adds a new platform. But if someone volunteers for this task I won't veto it. Oh, and it can easily be introduced by a CWS, so no Releng is needed for this :-). Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
