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

Finding a patch's kernel version with git

Finding a patch's kernel version with git

Posted Jun 21, 2010 9:36 UTC (Mon) by chad.netzer (subscriber, #4257)
In reply to: Finding a patch's kernel version with git by iabervon
Parent article: Finding a patch's kernel version with git

"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).


(Log in to post comments)

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 (subscriber, #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:
http://lsimons.wordpress.com/2010/02/19/using-long-lived-...

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?


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