Thomas Heller wrote:
On 03/21/2012 04:56 PM, Julian Gonggrijp wrote:
[...]
The second argument is more technical, and perhaps more convincing. It works even without branches or collaborators. All we need is a single developer who makes some changes to their working copy of a project.
[...]
Result: the units-of-work developer is spending less time to get the same thing done with less opportunity for errors.
Note that the pieces of history that tend to get altered in a units- of-work model generally don't make it into version control in a snapshot model at all. Sure, this all makes sense. Except that failures often only materialize _after_ you made your changes public. [...] So, to repeat, this all sounds nice and dandy, but after digging deeper, it doesn't sound like it is generally applicable. This is not just about bugs or private/public, this is about making changes to work. Even just changing your mind before you make something public already happens often enough to make local unit-of- work commits a feature. If a bug is found after the faulty code has gone public, small commits still help to better narrow down the changes that caused it and to reduce the amount of work that has to be done to solve the issue.
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,
Unless you can test _everything_ on your local machine, or you push onto a volatile branch, which opens a completely other can of worms (from what i understand). What can of worms? I don't recall reading any post that described a can of worms associated with volatile branches. Besides, /if/ you're altering volatile branches anyway, that's again way easier to manage with unit-of-work commits than with snapshot commits.
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". I completely lost track. I described my experience I had with. I was told that this was not the way to go, I am not sure if it is directly related to "changing history". But the problems existed. Now, force pushing (as i understand this is the only way to rewrite
On 03/21/2012 11:02 PM, Julian Gonggrijp wrote: this can be done any version control system (be it centralized or not). It is a matter of good habit. Though, as has been pointed out numerous times now, every approach comes with its own set(s) of problems. published history) essentially breaks every other clone of that public repository. This is exactly the can of worms I am referring to. 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. Or to formulate it differently: When is my public repository, which i intended for my use only, not private anymore?
-Julian
_______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost