On Tue, Jun 17, 2008 at 3:18 PM, Dennis Schridde <[EMAIL PROTECTED]> wrote: > Am Dienstag, 17. Juni 2008 09:02:13 schrieb Per Inge Mathisen: >> On Tue, Jun 17, 2008 at 12:35 AM, Dennis Schridde <[EMAIL PROTECTED]> > wrote: > Principle, yes. I am also against commits like "change style in a.c, b.c, ..., > z.c and add a tiny feature in k.c". For me the seperation starts to become > overkill when it goes like "change style foo(), ..., bar()", "add feature to > foo() which affects ..., bar()". I am already trying to seperate it a bit, > but if I would be asked to touch every block twice, once for cleanup and once > for changes, to get the patch out of the tracker and into the repository
It is not that difficult. svn diff > mypatch cp mypath mycleanup nano mycleanup (delete all real changes from patch) svn revert -R . patch -p0 < mycleanup svn commit I do this all the time. Or the other way around. I have a separate "clean" tree I use only for committing smaller pieces of patches, to get them down to minimum size before storing them for later and/or committing them for real. >, I would ask for payment. So who do you pay to fix the bugs? > but it's a cost/use calculation. How often do you read through change > commits which also cleanup the surroundings? And how often do you commit > things? Committing features is fun. Fixing bugs is very tiresome. In order for the quality of the game to remain constant or improve, and not degrade, we need to add restrictions to the former to improve the latter, not add obstacles to the latter to make the former easier. > But while I read through functions, I also add spaces here and there so I can > get a quick overview faster. Don't. Seriously, that is extremely annoying. - Per _______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
