Thomas Heller <thom.heller@googlemail.com> writes:
On 03/21/2012 11:02 PM, Julian Gonggrijp wrote:
Thomas Heller wrote:
Unit-of-work commits make it easier to find and review past work, reduce the burden on the developer to keep track of what they're doing until they're ready to publish it, and enable you to keep unfinished but versioned work around while working on other, more publish-ready changes. Unit-of-work commits really help you to manage and keep track of work, contrary to snapshot commits which mostly just provide a backup facility.
This is way more generally applicable than you seem to be willing to admit.
Sure, this all makes perfect sense. But this is not restricted to a DCVS, this can be done any version control system (be it centralized or not). It is a matter of good habit.
Indeed -- working in SVN or Git makes no difference here: you can (and should!) make small and self-contained commits in al systems.
You seem to suggest in addition that what we've been discussing here has something to do with cans of worms. Do you actually intend to suggest that unit-of-work commits introduce problems that don't exist for snapshot commits?
No, I am saying that altering history is dangerous! Which you described as one of the advantages of "the git approach".
Altering local (=unpublished) history can be convenient. It's considered an advanced feature in Mercurial -- you need to enable extensions for this. Git has a *bias* towards more history rewriting since it comes with these features enabled by default -- but it's still frowned upon if you rewrite public history in git.
In the context of boost, as a loosly coupled organisation, where i migh want to seemlessly switch, merge and whatever with other peoples work, this looks a serious problem. This is exactly the can of worms i was mentioning.
It's not a serious problem in practice. DVCS sounds like anerchy at first, but it's not much different from a centralized setup. You have a main repository (possibly on boost.org) and things that are pushed there are by definition final/immutable/frozen: they've been published and you must assume that people depend on them. So you just don't rewrite those changes. If you push there and find a bug, then you do the same as in SVN: you make a new commit that fixes the bug. Collaboration with a DVCS is really a question of making incremental append-only changes to a code base. That hasn't changed much from centralized VCS. The D in DVCS does allows you to pull changes directly from Alice or Bob if you like. That can be convenient for working on a feature outside of the main repo. But when the changes go to the main repo, they are just as immutable as in SVN.
Or to formulate it differently: When is my public repository, which I intended for my use only, not private anymore?
In principle, it ceases to be private when you put it on a public server, tell others about it, and they begin basing their own work on your volatile changes. If you publish a repository on GitHub and tell me about then I might look at the commits there and give you feedback. If I'm not basing any work on the changes, then it's no problem if you later destroy the commits and even delete the repository. But if you push the commits to a main repository on boost.org you cannot just change your mind like that: you must expect that others will have pulled the changesets and the cat is out of the bag. -- Martin Geisler aragost Trifork Professional Mercurial support http://www.aragost.com/mercurial/