| |||||||||||||
Finding a patch's kernel version with gitFinding a patch's kernel version with gitPosted Jun 21, 2010 15:48 UTC (Mon) by anselm (subscriber, #2796)In reply to: Finding a patch's kernel version with git by marcH Parent article: Finding a patch's kernel version with git
The underlying problem here is that SVN, being conceptually a souped-up CVS, basically deals in »snapshots of trees«. A branch in SVN is essentially just another subdirectory inside the repository (alongside »trunk«), and snapshots of the whole repository tree get numbered consecutively no matter where any changes happen. DVCSes like git, on the other hand, normally work in terms of »changesets«, i.e., atomic collections of patches to files in the repository. A branch is just a sequence of changesets that hasn't yet been applied to the main repository (the »trunk« if you will). The advantage of the changeset-based approach is that it is a lot easier to tell whether a repository contains a given change(set), where with SVN the system needs to try to infer this after the fact from looking at the files in question – which is why DVCSes are generally much better at merging than SVN. If the previous poster had used a DVCS instead of SVN, it would have been very obvious that the 4.0.1 bug fix had not been reintroduced to the mainline (i.e., the changeset incorporating the fix had not been merged), where SVN, on the other hand, didn't really help with this. The idea of numbering revisions consecutively even if that doesn't mean anything in the context of a branched repository is not one of the high points of SVN's design.
(Log in to post comments)
|
|||||||||||||