Subversion to Git Migration

  • 3,098 views
Uploaded on

A simple presentation where I discuss moving from SVN to Git for source code control management for a typical team

A simple presentation where I discuss moving from SVN to Git for source code control management for a typical team

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,098
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
83
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Case Study:
  • 2.  Introduction  Distributed Source Code Control  Git’s Features  Benefits of Git over SVN  SVN to Git Migration  Migrating from SVN to Git  How to use Git with SVN  Conclusion  Sources
  • 3. Section I
  • 4. Repositories URL Revisions Commits Commands Colors Visualize
  • 5.  With Subversion, for each project there is a single repository at some detached central place where all the history is and which you checkout and commit into.  Git works differently, each copy of the project tree (we call that the working copy) carries its own repository around (in the .git subdirectory in the project tree root). So you can have local and remote branches.  You can also have a so-called bare repository which is not attached to a working copy; that is useful especially when you want to publish your repository
  • 6.  In Subversion the URL identifies the location of the repository and the path inside the repository, so you organize the layout of the repository and its meaning.  Normally you would have trunk/, branches/ and tags/ directories.  In Git the URL is just the location of the repository, and it always contains branches and tags.  One of the branches is the default (normally named master).
  • 7.  Subversion identifies revisions with ids of decimal numbers growing monotonically which are typically small (although they can get quickly to hundreds of thousands for large projects). That is impractical in distributed systems like Git.  Git identifies revisions with SHA1 ids, which are long 160-bit numbers written in hexadecimal. It may look scary at first, but in practice it is not a big hurdle - you can refer to the latest revision by HEAD, its parent as HEAD^ and its parent as HEAD^^ = HEAD~2 (you can go on adding carrets
  • 8.  Each commit has an author and a committer field, which record who and when created the change and who committed it  Git is designed to work well with patches coming by mail - in that case, the author and the committer will be different.  Git will try to guess your realname and email, but especially with email it is likely to get it wrong. You can check it using git config -l and set them with:  git config --global user.name "Your Name Comes Here"  git config --global user.email you@yourdomain.example.com
  • 9.  The Git commands are in the form “git command <command_name>”.  Eg- “git commit …. “  You can interchangeably use the git- command form as well  Eg “git-commit ….”
  • 10.  Git can produce colorful output for commands  Colors are disabled by default
  • 11.  Watch your repository using the gitk repository viewer as you go.
  • 12. SVN Git
  • 13. Section II
  • 14. Import your SVN repo into Git • git svn clone https://svn.foo.com/svn/proj --trunk=trunk --branches=branches --tags=tags Make your own Git branch • git checkout -b work trunk Add the files you changed • git add <filename> Commit • git commit Want to sync with master SVN? • git svn dcommit
  • 15.  Why would we want this?  Since Git is a distributed revision control system (while svn is a centralized one) you can perform commits, brances and merges on your local working dir.  When you want, you will be able to “push” your changes back to the central SVN server  What are the advantages of this approach?  No downtime. Smooth migration  Existing system can run as-is while hooks are being written to integrate git into the system.
  • 16. • install git and git-svn Install • create the working dir Create • init your git working dir: Init • cd <workdir> && git-svn init http://your_repo • Find a commit regarding the project Find • the command git-log will show project’s history starting from this revision • Perform the command git-svn fetch –rREVISION Fetch • Where REVISION is the number obtained before. • Update your working dir: git-svn rebase Update • You can commit your changes using git-svn dcommit Commit
  • 17.  Sometimes, you may experience some problem when synchronizing with the main development tree.  In fact you have to commit all local modifications (using the git- commit command) before invoking git-svn rebase.  Sometimes it isn’t reasonable since your changes are not yet ready to be committed.  git has a native solution also for this problem, just follow these steps:  put aside your changes using the command: git-stash  update your working copy using: git-svn rebase as usual  take back your changes typing: git-stash apply  clear the stash by typing: git-stash clear  After the first step all your uncommitted changes will disappear from the working copy, so you’ll be able to perform the rebase command without problems.  For further informations read git-stash man page.
  • 18.  A DSCM gives a lot of flexibility when development is happening across various team.  Care needs to be taken while doing an SVN  git migration.  SVN & git should be used simultaneously until the team is confident about git.