It's all getting a bit unnecessary here. My comment was about a new file; I did not see the point of including properties that are not going to be used. I did not veto the commit; it was just an observation.
Having said that, if the properties are set it might suggest that they can be used. But so long as the properties aren't actually used, the only downside is the trivial amount of extra disk space needed to store the property, and possibly a tiny extra processing load when the SVN client checks for usage of the property. On 19 March 2013 11:30, Benedikt Ritter <brit...@apache.org> wrote: > Hi Simo, > > > 2013/3/19 Simone Tripodi <simonetrip...@apache.org> > >> Hi Bene, >> >> >> >> >> which is the side effect of having them enabled and not used? >> >> we are no longer using Revision and Date for the known reason, so even >> >> if they are enabled... what's the downside? >> >> >> > >> > I'm playing the devil's advocate here: aren't you the guy you tries to >> > avoid unnecessary code/config as much as possible? I'm thinking of our >> > discussions regarding static imports... ;-) IMHO this also applies here. >> > >> >> just for the sake of satisfying the lawyer inside you: >> > > I don't see why this statement was necessary. > > >> >> I asked, accidentally without using the `please` word - and please >> take note that it is not my usual habit -, to explain where the >> _issue_ that needs to be fixed is, on having properties enabled that >> are _not used_ - again, this is "unfortunately" my default SVN config >> that has to be compliant not just with Commons, which is not the only >> project I am involved in. >> > > The problem with this is, that it is _unnecessary_, just like unused > imports, unused local variables or unnecessary casts etc. are. > This is only partly related to our discussion regarding the $Date$ keyword. > Setting a keyword that we have decided not to use, just adds another > argument for removing it. > > [fileupload] is probably in the same state like [beanutils] (and a lot of > other components) so I guess, that all files have svn:keywords= Date > Revision Id HeadURL. > Making bulk changes like this is a bit tedious (I've learned that when > changing from $Date$ to $Id$ in [beanutils]) but should be done. > If I can help with the development of [fileupload] by going through all > files and removing unnecessary keywords, I'll do that asap (probably this > weekend). > Agreed? > > >> >> In this case, my friend, you are overkilling the discussion and rather >> than having a tech argumentation here, you are trying to put ME on the >> debate - I don't understand what did you want to demonstrate with this >> message, or maybe I want to refuse to understand. >> >> Ah, and BTW, at the time of static imports, there was not a problem >> that needed a fix: we had two different opinions and you put efforts >> on proving that mine was wrong, where at the end of the day what >> emerged is that both are valid. >> > > If this is what you took from our discussion I'm a bit surprised. > As I indicated on the other thread [1], the discussion with you guys is one > of the things that make the most fun (apart from the actual coding ;-). > I have the feeling that discussions are a bit harsh lately, and I don't > know where this is coming from... > If you feel disturbed by my comments I'm sorry. That wasn't my intention. > > Getting back to our discussion (which I found very refreshing): I tried to > make my point clear and of course _discussing_ always involves trying to > convince others, that ones opinion is right (or getting convinced from the > opposite). > I didn't start the discussion (or any other discussion) just for the sake > of discussing. > This would be stealing your free time and that is certainly not what I want > to do. > I'm not the kind of guy that always wants to have the last word (I think > you know that). > > Tanti saluti, > Benedikt > > [1] http://markmail.org/message/o7ef6o4ahe23k5iu > > >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > http://people.apache.org/~britter/ > http://www.systemoutprintln.de/ > http://twitter.com/BenediktRitter > http://github.com/britter --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
