User: Password:
|
|
Subscribe / Log in / New account

Controvery over commit styles

Controvery over commit styles

Posted May 27, 2010 11:52 UTC (Thu) by epa (subscriber, #39769)
Parent article: Interesting times for Linux Flash support

Did anyone suggest the obvious answer of moving to a distributed version control system? Then any developer can commit as often as they want to their own tree (or branch), and only push (or merge) when the changes are stable.


(Log in to post comments)

Controvery over commit styles

Posted May 27, 2010 15:14 UTC (Thu) by JohnLenz (subscriber, #42089) [Link]

IMO for a distributed revision control there is even more pressure to make sure each commit is a working piece of code. The reason is bisection: once you switch to a distributed revision control you can start to use bisection to find problems, but bisection fails (or at least makes your life more complicated) if there are intermediate commits which are broken in some way.

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) [Link]

Sure the pressure for good working atomic commits is high when you can have working bisection in a DVCS. This is a good thing.

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.

Controvery over commit styles

Posted May 27, 2010 17:01 UTC (Thu) by hmh (subscriber, #3838) [Link]

Yes, you're correct. On the other hand, there are already numerous tested and proven workflows to implement both the bissectability and clean history, AND allow for the work-in-progress dirty history.

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.

Controvery over commit styles

Posted May 28, 2010 9:20 UTC (Fri) by marcH (subscriber, #57642) [Link]

If your changes are so disruptive that they need to break the test suite then you should simply work in a isolated branch, so other developers can keep working. Distributed version control makes that easier but is not strictly required.

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.

Controvery over commit styles

Posted May 29, 2010 3:20 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

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.

Controvery over commit styles

Posted Jun 1, 2010 16:17 UTC (Tue) by epa (subscriber, #39769) [Link]

Well, there's the distributed side, and there's the 'make branches and merge them without going insane' side. If your version control system supports easy branching and merging, you can commit your stuff to an unstable branch or a personal work branch, where they are visible to everyone but don't break things for others until you're ready to push them to the main branch.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds