On Mon, May 02, 2011 at 12:58:53AM +0200, Pavel Sanda wrote: > Peter Kümmel wrote: > >> - Less noise in commits: a new feature in SVN sometimes comprises over 20 > >> commits in > .. > > The commits are the beats of LyX's development heart, so why kill them. > > there is actually something on this. > > its good idea that having some "final" tree where 1 feature=1 commit.
> its blessing when you dig out something in history. it would spare amounts > of my time when bisecting history to find regression culprits. For bisecting I found it really useful to have not-so-fat commits. The bisecting itself is only logarithmic in the number of commits and automatable, whereas finding the actual bug in the faulty commit is linear in the size of the commit and typically manual. I don't think there's something wrong with having a big feature in a dozen commits, as long as all of the intermediate versions are working, and preferably if the version represent "logical steps". Prepering some infrastructure, maybe some refactoring, the actual feature work and finally enabling it is not an uncommon pattern. By separating the final "enabling" part from the infrastructure work which might be directly or indireactly used later use cases like "temporary removal of a feature" (testing purposes or whatever) are covered, too. So I would not be too restrictive when selecting the "True Workflow". > on the other i find the above "beats" important for life of the > community around dev list, so whatever dev model we adopt some > git-commit mailing list where things go imeddiately not waiting for > some final merged or approval feature-commit is must-have imho. That's starting to look a bit over-engineered and the need to implement an "out-of-band heartbeat notification scheme" might be a problem of the primary approach then. It's incidentally less prominent in a "1 feature = a reasonable smallish number of commits"... Andre'
