Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Controvery over commit styles
Posted May 27, 2010 15:14 UTC (Thu) by JohnLenz (subscriber, #42089)
Especially the test suite breaking in a commit, because the test suite failures would be what you probably would be bisecting.
Micro-commits versus non-regressive commits
Posted May 27, 2010 16:33 UTC (Thu) by alex (subscriber, #1355)
However I've often noticed with central VCS systems the pressure to commit before your set of disparate changes become too extensive.
Using a DVCS can alleviate that pressure by allowing you to develop locally with multiple small commits. Once you've fixed your regressions you can re-base into nice tidy commits, re-test and then push to the public repository.
AIUI Gnash is already using Bazaar so it really should be possible to have a clean commit history without breaking stuff on the way.
Posted May 27, 2010 17:01 UTC (Thu) by hmh (subscriber, #3838)
In the simpler one, you use at least two work branches, plus the mainline branches. You move the ready-and-tested work from the dirty work branch to the mainline through an intermediate cleanup branch. The no-mess, no-regression, clean history for bissectability requirements exist only in the mainline and intermediate cleanup branches.
Posted May 28, 2010 9:20 UTC (Fri) by marcH (subscriber, #57642)
That such engineering basics are unknown to the Gnash developers says a lot about the project.
There is LESS pressure in distributed revision control to make sure each commit is a working piece of code, since it is much easier to rewrite history and get rid of such "breaking" commits later.
Posted May 29, 2010 3:20 UTC (Sat) by giraffedata (subscriber, #1954)
Isn't the point of "commit early and often" to get your code in front of everybody? Using a distributed version control system does that only insignificantly better than just keeping it in your CVS working directory. (Better, I guess, because someone sufficiently motivated could see your work early).
Breaking things for everybody is the acknowledged downside of commit early and often. Obviously, there's a difference of opinion in this project over whether the upside outweighs that.
Automated test suites that are part of a quality control strategy don't seem to me consistent with commit early and often, which admits that the code is going to be broken a lot.
Posted Jun 1, 2010 16:17 UTC (Tue) by epa (subscriber, #39769)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds