23 Jul
2013
23 Jul
'13
4:37 a.m.
Nice policy Martin. Never looked at it that way, I always tried to have working code in dev-branches and just as you say, I tend to get stuck second-guessing. The last year(s) continuous integration and workflow discussions in different forums might have focused a little bit too much on working code.
Regards
--
Christoffer Holmstedt
2013/7/23 Martin Owens <doctormo@...400...>
> On Mon, 2013-07-22 at 18:58 -0300, Vinícius dos Santos Oliveira wrote:
> > I like to make commits that don't break. Following this rule, I also
> > like to make small commits that change small parts of the code and are
> > easy to track.
>
> The policy I follow is:
>
> Is the branch going to be released -> trunk==yes, dev-branch==no
> Breaks should be avoided in released branches but encouraged in
> dev-branches. It sounds odd to encourage broken code, but the more
> adventurous and the less shy, the less likely developers spin their
> wheels while their subconscious calculates risk vs reward and get stuck
> second-guessing the ability to hit a home run with every contact with
> the code.
>
> Broken code can be fixed, uncommitted or reversed, non-existent code
> can't even be seen.
>
> Small changes is a good plan, nice and smooth. Easier to see the
> progression and once merged all those get collapsed into a nice subtree.
>
> Martin,
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clk...
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>