Git does a lot of things better than any other VCS:
#Subversion conflict resolution code
SVN and other VCSs may take so long that a developer who is, say, trying to trace the changes that caused a bug may feel it’s easier to go through the code himself than run a ‘diff’ against the last known good version! That is, these VCSs have the tools but it’s a pain to use them! (P) common VCS operations do not need network or server access, and are blazingly fast. Merge-conflict resolution happens on much smaller units instead of one huge chunk of code dumped on the repo! In SVN, every commit goes to the server, forcing commits to be large and monolithic, in turn causing every merge to be a serious exercise rather than a couple of minutes work. (P, M) devs make lots of small commits instead of one humongous commit – much easier for code review, debugging, cherry-picking, and merging with other changes. In SVN, a successful side project is forced to enter the main project as one large chunk of code, which seriously affects future maintainability. If the experiment worked, you bring it into the main repo (without losing the individual commits), otherwise you toss it.
#Subversion conflict resolution full
(P, M) devs can create local branches without polluting the central server – experimental features can be developed and tested “on the side”, with full revision control and granular commits. Also, SVN may become confused when files are modified and renamed in the same commit.) That is not the only brittle aspect renames and merges don’t mix well, apparently. (M) handles file renames correctly helps in refactoring (in SVN, a rename is handled as a delete of the old file plus an add of the new file, and it is only tracked as such if you explicitly told svn about the rename. (P) handles merges automatically (in fact SVN doesn’t really “handle” merges merge history must be manually recorded and managed, and it’s almost impossible to have 2 branches merging regularly in SVN without a lot of pain for the integration team) Git’s advantages over SVN (all of them affect productivity and/or maintainability, indicated in parens as P or M) are: If there are errors in the SVN part of this description please let me know. What follows is my understanding of the SVN scenario, from various sources. ^^as Churchill said, so much to do, and so little time in which to do it… ( sigh)^^
Lots of SVN info is scattered in a few other files in this directory eventually it should all be pulled into this file. Gitolite documentation has another /gitolite in the URL, so "" and so ALL my git related stuff gets carried over.
That's just an artifact of "" being translated to For people who think SVN is good enough -)Īlthough this page has a "" URL, this is not about gitolite.
0 kommentar(er)
