On 2011-08-15, Dominik Psenner wrote: > On 08/15/2011 07:26 AM, Stefan Bodewig wrote: >> I think it is important for us all, that we do have a single place with >> the code to discuss - and once we have enough people with write access >> it won't be necessary to think about any other place than svn for this.
>> The "hg or git clone of svn" model works very well for the odd case of >> people who want to contribute larger patches but don't have write access >> themselves - which should be the exception. > And it makes sense in cases where people work together on a bugfix > without the need of spamming the svn log with stuff that doesn't work. That's what I meant when I said the approach allows contributors to have the advantage of revision control while developing the patch. Most of our patches aren't really that big, though. There won't be much back-and-forth. svn logs of failed attempts do provide some value as well, BTW. If there is anything bigger to develop, a svn branch can work as well - contrary to popular belief, svn does support branching and merge tracking and it isn't all bad. Note, the ASF has used and survived CVS before. ;-) > Right now the most useful log4net that people use is the svn trunk. We > shouldn't break it! If we get back on track with regular releases the occasional trunk breakage will be OK as people won't be forced to use arbitrary trunk revisions. > Indeed the history how a single patch evolves is not at ASF, but since > patches should be sent to the mailing list Nope. JIRA. > and discussed there (mbox extension) it is not that far from ASF at > all. > Please correct me if I'm wrong. No, you are not wrong per se. But for simple cases it is more complex than what I'd do otherwise. Looking through your explanations how to review certain patches I thought the old fashioned way would be way easier for anybody with svn write access. My typical workflow for any other ASF project is * read the bug report and the attached patch * if it looks reasonable, apply the patch to my local working copy of svn trunk (that's patch -p0 < patchfile). * rebuild the tests, run them and watch them fail * rebuild main code base, rebuild the test, run all tests and watch them pass * commit Of course this is an oversimolification and I may very well stop at "read the patch". And TBH many times I drop the patch, apply only the tests and write a different fix myself - and even more often there is no test and no patch at all. In the case of no patch and no tests it doesn't matter that the only repo I have is svn. Stefan
