Hi all, Maât a écrit : > Caeies wrote: >> Hi all, >> >> I'm happy to see new logs in the svn. But I have to urge all devs to be >> *very* carefull when commiting in the repository. >> As maat suggest having an easy understable log is important. I will not >> focus in this email on this, but I think that the way he proposed to >> "tag" logs is a good idea. >> The real focus in this message is this : >> Each commit *in trunk* should be "atomic". I mean, that if somebody do a >> checkout, trunk should be "usable" after each commit. You are free to >> do whatever you want in your own branch (but I would recommand to stick >> to this policy), but not in trunk. Reasons are : >> - easily review patches >> - easily merge >> - no missing files for people >> - ... >> > I'll add also : > > - stable > - tested > - reviewed by peers if the change lets some questions unanswered > > Let's take an example with the following : > > Log Message: > ----------- > Bug fix : try to fix the get_member stuff, not sure if this is the right way > to do it, but it works > > > Commits with some uncertainty and "i'm not sure" comments like this one > should not imho be committed straight in reference repositories but > rather in personal repositories and should trigger a call for review :) If trunk was bug free, I will be ok with this way of working. Unfortunately, trunk is far away such a base, fixing it like this will be easier. Note that I speak about _fixes_ and not "new features" ... and IMHO this is a real difference.
> > Then, once the patch is tested/reviewed/improved, you can merge the > (perhaps improved) changes in one single commit with a > professionnal-looking comment like for example : > > Bug fix : replaced the inexistant variable $this->account_id by the > existing $account_id Well If this is what you understand of the patch ... damn, review can take long time :). It's not because I take care of doubt in my commit that I'm not sure of what I do ... > > As we are starting from a low level of quality as far as sources and > changes control management is concerned we can close eyes a moment and > go on fixing things without too high expectations on process quality but > keep in mind that we'll need to improve this sooner or later (dunno if i > can use this for the french expression "tôt ou tard") if we want to use > svn logs to generate good looking Changelogs :) IMHO this should be done when merging new features... from personnal branches. Btw, before doing a commit I'm near always doing a svn annotate and take a look at the people who commited in and the associated log ... Regards, Caeies _______________________________________________ phpGroupWare-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
