Git vs cvs ece2011

1

Git from a different (CVS/SVN) perspective

Christian Campo
EclipseCon Europe 2011

Confidential | Date | Other Information, if necessary
November 7, 2011 © 2002 IBM Corporation
Copyright © 2011 compeople AG, Made available under the Eclipse Public License v 1.0

Git vs CVS vs SVN

Git
• commits like db transactions
• commits linked in a hierarchy
• commits contains for a collection of files
• decentral repo
CVS
• commits are unrelated file diffs
• central repo

SVN
• commits are file diffs
• commit file diffs can be linked with a common revision
• central repo


Git Promises/Claims

 you get your own local repository
 you can commit even offline (in an airplane)
 branching is easy and no longer an unusual task but part of your
everyday workflow and its so much easier with Git
 you hated merging with CVS (SVN) ? you are going to love it with Git
 Git is fast and easy
 you cant run an open source project without Git


Git promises from the CVS angle

 you never wanted a local repository
 you hate toonly checkout a wholecommit in an airplane (modules)
• you can fly and therefore never repo with all projects
• you Internet now officially of the last 1-5
 you hate branches andhistory everywhere ? years
• isnt get the whole actually never create them yourself
• and even if you are offline, just write code for a change
• and all branches
• your release engineer does that
 you have a different definition of merge, if two people modify
• so now you should MERGE.
unrelated files thats NOcreate branches ? NO way
• branches isnt that like a fork ?
 Git is fast ! but not easy
 successful open source only requires Git....seriously ?
• no javadoc
• no unit tests
• no clean code
• no integration tests
• JUST Git ??


Git is giving words/things a new meaning

 commit does not mean everybody can see your code
 merge happens even if you edit unrelated files
 first commit THAN merge THAN possibly commit again ??
 and then....the merge commit is empty ? (has no diff)
 repository is not one central thing on the server but everyone has one
 branches on client and server can have different names
 its ok if two repos dont carry the same branches/tags


CVS Users Migration Steps

Step 1: Resistance


CVS has a real Synchronize

 Synchronize shows me the list of incoming and outgoing changes on
file level
 helps to not check in stuff that I dont intent to
 often people check incoming changes on a detailed level
 helps to understand what other people changed
 refactor stuff that seems wrong
 check typos :-)
 improves the quality of the code
 update is done step by step like kind of a to-do-list
 there is Synchronize in Git, but you can not incrementally update
(because of the concept of Git)


Things only CVS can do

 you can tag projects independant as you go
 you can tag single files later
 selectivly update only some projects
 NOT resolve conflicts when you update (i.e. a xx.launch file that you
changed)


CVS Usage is NOT problem free

 If you branch you almost never merge (because its so hard)
 it was always complicated to figure out what was changed for a certain
changeset ?
 A "changeset" are merely commits with the same message so it is easy
to amend a commit :-)
 did you ever tag before and after a commit to log the difference ?
 if you develop in HEAD and a version branch und later you have to copy
changesets from HEAD to the version branch


More CVS crap

 Refactoring (renaming a class) means loosing all your history
 Renaming a package, project means loosing all history of all objects in
that package/project
 If you delete a project it does not get deleted at your collegues
workspace committer unless you TELL him. (and he deletes it
manually)
 If you add a project your collegues wont find out until you TELL them.


And you come to Git...

 And people tell you....
the easiest way to use Git is the command line
 however the command line is way better than you expect
 it was created to actually work with it on a daily base


CVS User Migration Steps

Step 2: Euphoria

„Git is CVS without its problems, I have“


Pitfalls in Git

 you try to pull before you committed your changes
 you push .... EVERYTHING (including all local branches)
 you create a new project in the root of the Git Repository directory


Pitfalls in Git II

 Merge conflicts are a little more complicated
 CVS flags the conflict
 Git Pull actually puts a comment in the file (so that it doesnt compile)
 Rebases can be scary (rerunning commits on a different branch and
hoping that the commits also work there)
 Merge conflicts in the middle of a rebase even more
 You always have to update everything (no way to exclude a bundle or a
file)


More stuff...

 CVS users moving to Git think that Git is the solution to everything they
missed in CVS
 yes moving content between files means that Git still can keep track of
the history
 try to rename a bundle (just for fun) and then look at the proposed
commit (there is “git mv” though)
 you hear that the Git repo of the Eclipse platform was corrupted by a
single committer (Is Git the right move for me ?)


CVS User Migration Steps

Step 3: Realtity

Understanding what you can do


Where Git is better than CVS (the centerpiece)

 commits
 changes collected together in one metaobject called commit
 put more effort in creating a good commit
 amend a commit if wrong, dont just add a second (like in CVS)
 make smaller commits
 commits should be a "unit-of-work" useful by itself
 a good history is the key to using Git
 only Git commits truely show which modifications where committed
together
 there is no commit in CVS !!! Its just writing a collection of diffs..


Things only Git can do

 Pick some commits from one branch into another (cherrypicking)
 Revert commits
 Merge branches (and that actually works :-) )
 Rebase your local changes on top of the server master
 Work on commits in the past
 Tag them
 Branch from them
 Sign them
 Reset your workspace to that time in history
 If you manually undo the changes in a file it automagically shows the
file as unmodified.


Things only Git can do

 develop multiple features in parallel without checking-into-the-server-
repo
 stash your current work, while you do something else and then come
back to your work in progress
 commit only parts of the changes in a file
 freeze a state of your files before they are committed (staging area)


Git is confusing at times

 It uses names that CVS uses, but means something different
 commit, merge, repo
 local tracking branches can have a strategy
 git history can be confusing and complicated


Summary

 Dont treat Git as if it were CVS.
 Getting from CVS to Git
 requires you to "re-wire" your brain
 get used to a new way of doing things
 adapt your way of doing things to retain your workflow as much as
possible
 Symptoms are similar to learning any kind of new technology
 remember XML, Javascript, Objective-C, Modeling, XText, Tycho
 Git opens the door for better collaboration and contribution from
others


And...one more thing....

...you can commit in an airplane


Git vs cvs ece2011

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Git vs cvs ece2011

Similaire à Git vs cvs ece2011 (20)

Dernier

Dernier (20)

Git vs cvs ece2011