Git vs Subversion: ¿Cuando elegir uno u otro?

GIT VS. SVN
Which one should we use and when?
http://www.paradigmatecnologico.com
@paradigmate
http://marianonavas.me
@marianongdev

What is a CVS for?
• Allow team work together and collaborate
• Have some kind of time machine in our code
• Allow CI

Approaches (architectural models)
• Local
• Rcs (Mac OS Developer Tools)
• Centralized
• Subversion
• CVS
• Perforce
• Distributed
• Git
• Mercurial

Centralized
• Pros
• Looks simple
• We know it well; we've been using it for a long time
• Good mainstream IDEs integration
• It works 
• Cons
• We cannot commit offline (well, we can, but …)
• We cannot integrate in our development toolset more than one
repository
• Dificult to collaborate if team is large (i.e. open source projects)
• We are encouraged to avoid branches by the system.

Distributed
• Pros
• Allow offline work
• Easy collaboration model
• Can link as many repositories as we might need
• Almost every operation is local
• Complete copy of the repository in each machine
• Easy installation on server, and plenty of hosting services (free and
paid)
• Cons
• More complex workflow (or not?)
• Difficult to learn
• ?????

Internal representation of data; SVN

Branching in SVN
Quotes taken from official svn website
• "For projects that have a large number of contributors, it's common for
most people to have working copies of the trunk. Whenever someone
needs to make a long-running change that is likely to disrupt the
trunk, a standard procedure is to create a private branch and commit
changes there until all the work is complete"
• "The bad news is that it's very easy to drift too far apart (...) it may be
near-impossible to merge your changes back into the trunk without a
huge number of conflicts"
• "Subversion gives you the ability to selectively “copy” changes
between branches. And when you're completely finished with your
branch, your entire set of branch changes can be copied back into the
trunk. In Subversion terminology, the general act of replicating
changes from one branch to another is called merging, and it is
performed using various invocations of the svn merge subcommand”

Branching in SVN I (typical workflow)
• Checkout from trunk.
• Add a new file to working copy
• Check status (svn st).
• Track new file in svn (svn add).
• Commit the new file (svn ci).
• Modify the file, and check status again (svn st).
• Commit the new change.
• Modify again and let it remain modified.

Branching in SVN II (branch & merge)
• Svn copy at server level.
• Check current working copy remote path (svn info).
• Switch to new location (svn switch [remote] .)
• Check remote again (svn info).
• Commit some change to the branch.
• Switch again to trunk.
• Merge trunk with [myNewBranch] (svn merge [source@rev] .).
Note that we do it with the working copy first to merge conflicts
locally.
• Commit to finish merge (we’ve done it locally in the previous
step).
• Again with a non-conflicting change in the same file.
• Again with a conflicting change.

Internal representation of data; svn
• Repository: the main idea
• Working copy
• Revisions, which are deltas of a base state
• The server has to workout deltas to resolve the concrete
state of a revision (commit)
• Each revision gets a unique (secuential) id. This is
possible because it's centralized
• Branches: are light copies of complete working trees
• Summary: branch=copy.

Drawbacks II: branch & merge sucks
• Recall branch & merge procedure:
• Copy trunk in branch directory in remote server
• Checkout (or switch) locally.
• Inspect revision we want to merge with, if not last.
• Call svn merge.
• Resolve conflicts (if any).
• Commit the whole thing.
• In practice we feel encouraged to not create branches
(bad, bad, bad …).

Drawback III: cleanliness
• What if I want to merge my branch just to get up to date
with our trunk, but I don’t want to make it public yet
(incomplete feature or just playing around)?

Drawback IV: privacy
• Do I have to publish my code to a remote/public server to
have version control? What if I’m doing some experiments
I don’t want other people to see, or I just don’t want to
mess up our central repository with something I don’t
know if it’s going to work?

Internal representation of data; git

Git internal storage structure: directed
acyclic graph (DAG)
• http://eagain.net/articles/git-for-computer-scientists/

Deeper insight in git DAG internal
structure

Another view of git objects II

Another view of git objects III

Details on how git stores that in disk
• http://git-scm.com/book/en/Git-Internals-Git-Objects

More on git internal representation of data
• http://en.wikipedia.org/wiki/Directed_acyclic_graph
• Due to its distributed nature unique ids for commits are
generated as SHA-1 digest to ensure unicity
• Explanation
• Snapshots, not deltas
• Commits: blobs
• Branches: references to commits
• Repeat: branch = pointer
• Current branch: HEAD pointer
• Detached heads: careful

SVN branch & merge summary
• SVN has no branch concept. It's just another working
copy with a common history
• We can only merge two branches at a time
• SVN allow you to merge even not at all related trees
(error prone)
• Refactor and moving things around; svn doesn't manage
this kind of merges very well
• Only allows interaction one repository at a time.

Git branch & merge summary
• It’s trivial to create a new branch from any point.
• Git prevents us from deleting unmerged branches.
• We can clean up obsolete branches keeping commits.
• We can move a branch around (recreate it from any
starting point).
• We can merge more than one branch at a time (3 or even
more!!!).
• Git understands moved and renamed files.
• This model encourage best practices: branch-per-feature,
local branches for testing and experiments, git-flow …

Git allow us to manage branching well

Interesting git resource
• http://git-scm.com
• http://git-scm.com/docs/gittutorial
• http://try.github.io/levels/1/challenges/1
• http://www.vogella.com/articles/Git/article.html
• https://help.github.com/articles/
• http://gitimmersion.com

Wich CVS should I choose and when?

Git vs Subversion: ¿Cuando elegir uno u otro?

Recommended

More Related Content

What's hot (20)

Viewers also liked (14)

Similar to Git vs Subversion: ¿Cuando elegir uno u otro? (20)

More from Paradigma Digital (20)

Recently uploaded (20)

Git vs Subversion: ¿Cuando elegir uno u otro?