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.clktrk
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...1794...s.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel