> > And finally could I say that tracing the patches and reasons for > > changes is very difficult when you haven't got an issue for them, > > with full logging of issue number in SVN checkin messages; and SVN > > revision numbersin the issue. > > I see what you're hinting at. I'm not sure, though, this "double > bookkeeping" is feasible for us, but that's only my 2 cents.
I've been doing it for years. We even have Tortoise SVN configured to require a bug number (or list of bug numbers) for a checkin. So our developers can't commit code unless there is a bug allocated. In the case of this work you remember where the discussion was about the changes because they are fresh in your mind. But in one year's time you will forget and trying to track down why something was done is very difficult. Someone who has skimmed this thread will have difficulty tracking it down from day 1. This is particularly the case where there is a bit of code which doesn't appear to have any reason for being there. If your comments in the code aren't clear then the next resource to use is to look for the bug and discussion about it. SVN Blame is very useful for finding the checkin which modified a line, but then finding the reasons why can be difficult if there's no cross-referencing. If you have full regression and code coverage testing you can be less concerned as you can just delete the dodgy code and see what happens - but I don't think you've got that. It might take some more time when checking in - but it certainly saves time when maintaining code later. Hugh ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
