| |||||||||||||
Finding a patch's kernel version with gitFinding a patch's kernel version with gitPosted Jun 18, 2010 16:40 UTC (Fri) by iabervon (subscriber, #722)In reply to: Finding a patch's kernel version with git by marcH Parent article: Finding a patch's kernel version with git
The situation is actually:
2.6.33 Release
In a centralized system, it would be obvious whether the bugfix would have to be backported to the 2.6.34 release; with a decentralized system, it requires inspecting the commit graph. However, with a centralized system, the bugfix would have to be backported to the 2.6.34 release, because the bug was in work that was committed before the 2.6.34 release; with a decentralized system, merging new development could be put off until after the release without making it harder to do the development, so the bug was not in the 2.6.34 release.
The unstated assumption in many comparisons is that, in a centralized system, the item labeled "2.6.33+5" above would have been where the item labeled "2.6.35-rc1" is, but this is unrealistic because it would require the developer to either wait until that time to write the code, or leave the change uncommitted and wait until "2.6.35-rc1" to do any other work. With the order of events fixed, it becomes clear that the choice is between thinking a release had a bug and being right, and thinking a release had a bug and being wrong.
As a general rule, bugfixes get considered for backporting at the point where they are merged into the mainline, and it's obvious at that point that no release contains them yet (you can't tell from the bugfix commit whether it missed a release, but you can tell from the pull request). The interesting question is when the bug was introduced, since that determines what backports are needed, and these backports go into patch release branches which have linear histories. When considering whether a fix is in 2.6.33.N and looking at the commit that fixes it for 2.6.33.*, you can just look at the commit dates.
(Log in to post comments)
Finding a patch's kernel version with git Posted Jun 21, 2010 9:36 UTC (Mon) by chad.netzer (✭ supporter ✭, #4257) [Link]
"In a centralized system, it would be obvious whether the bugfix would have to be backported to the 2.6.34 release; with a decentralized system, it requires inspecting the commit graph. "
How is this true? Not all feature branches in a centralized system need be merged before a release, and so it seems to not be a matter of centralized vs. distributed. Bazaar supports both centralized (ie. non-local commit, merging, etc.) and full DVCS semantics (local branching/merging), and I'm having a hard time seeing how your example would not require graph inspection in either mode, since the commit was written before a release, but merged afterwards according to the comment.
If you simply require all branches in a centralized system to be merged before a release, with non-merged branches to be re-written/rebased off the latest release, then that's one thing. But that can be enforced in a distributed system as well (though it sounds like a painful policy, more painful than whatever it intends to fix).
Finding a patch's kernel version with git Posted Jun 21, 2010 16:12 UTC (Mon) by iabervon (subscriber, #722) [Link]
The distinction is really as to whether the development is forced to be linear by having only a single branch, or whether there are multiple branches. Obviously, a decentralized system has to have multiple branches, because each branch can only have one authoritative source. And it has historically been the case that systems designed to be centralized either don't support branches or don't have the necessary merging support to make long-term feature branches feasible, which means that changes which are written before a release and aren't included in it won't be merged (or, at least, the project history that people will see for versions that get released won't include the history of the change as was recorded there).
So, if you understand a system to be "decentralized" if the software includes the necessary features for not having a central repository, even if it is used with a central repository in actual deployment, then the systems still considered "centralized" essentially require all branches to be rebased around a release just because merging them is otherwise too hard to get right.
Finding a patch's kernel version with git Posted Jun 21, 2010 19:45 UTC (Mon) by chad.netzer (✭ supporter ✭, #4257) [Link]
Ah, this also explains marcH's points a bit better. I still contend that this is not a "centralized vs. distributed" issue, then, but really a matter of linear vs. non-linear history, and branch management between releases. Certainly the "centralized repo" tools that I'm familiar with have gained better branch and merge support over the years, and more easily support long lived branches and feature branches, without rebasing after each release.
Here is an informative workflow example, demonstrating marcH's "strict ordering" principle:
It works in this case because trunk has no other branches than stable, and stable is (obviously) never merged back into trunk. That same workflow works even with a distributed system (by rebasing before pushing to the main repo, for example). It blends history among developers, however, which can be a disadvantage at times, especially with many developers and features in active development.
Finding a patch's kernel version with git Posted Jun 29, 2010 14:58 UTC (Tue) by marcH (subscriber, #57642) [Link]
> I still contend that this is not a "centralized vs. distributed" issue, then, but really a matter of linear vs. non-linear history, and branch management between releases.
Agreed I guess, except you conveniently omit the huge influence that a centralized system has on branching policies (the "workflow").
> Certainly the "centralized repo" tools that I'm familiar with have gained better branch and merge support over the years,
As long a system is centralized, you will neither be able to permanently erase branches nor to re-organize the past in any way. And you will need some human-level protocol to avoid collisions. These, and probably others reasons I miss will always have a chilling effect on branching. Why do you think git-svn is so popular?
I am pretty sure that the main reason why most decentralized systems were invented is because their authors wanted to increase the branching and merging freedom.
My point here is that the tool has a huge influence on the way it is used. Sure you can often hammer down a nail with a screwdriver, but do people do that routinely?
|
|||||||||||||