Git&subversion
Download as PPTX, PDF0 likes413 views
This document compares centralized version control systems like Subversion to distributed version control systems like Git. It discusses how version control systems track changes to files over time, allow checking files in and out for editing, and help resolve conflicts when multiple people edit the same files. Centralized systems store files on a central server, while distributed systems allow full copies of the code to be stored locally. The document outlines advantages of Git like speed, ability to work offline, and ease of creating branches compared to Subversion.
Git&subversion
- 2. WORKING ALONE ▪ Had code that worked, made a bunch of changes and saved it, which broke the code, and now you just want the working version back… ▪ Accidentally deleted a critical file, hundreds of lines of code gone… ▪ Somehow messed up the structure/contents of your code base, and want to just “undo” the crazy action you just did ▪ Hard drive crash!!!! Everything’s gone, the day before deadline.
- 3. WORKING IN TEAMS ▪ Whose computer stores the "official" copy of the project? ▪ Will we be able to read/write each other's changes? ▪ Do we have the right file permissions? ▪ Lets just email changed files back and forth. ▪ What happens if we both try to edit the same file? ▪ Kareem just overwrote a file I worked on for 6 hours! ▪ What happens if we make a mistake and corrupt an important file? ▪ Is there a way to keep backups of our project files? ▪ How do I know what code each teammate is working on?
- 4. SO WHAT CAN I DO?
- 5. VERSION CONTROL SYSTEM ▪ version control system (often called a source code control system) does these things: ▪ tracks incremental versions (or revisions) of files and, in some cases, directories over time. ▪ allows you to explore the changes which resulted in each of those versions ▪ Allows “check in” and “check out” of files so you know which files someone else is working on ▪ Displays differences between versions
- 6. HOW IS IT WORK?
- 7. VCS USES A REPOSITORY ▪ check in: adding a new file to the repository ▪ check out: downloading a file from the repo to edit it ▪ you don't edit files directly in the repo; you edit a local working copy ▪ once finished, the user checks in a new version of the file ▪ commit: checking in a new version of a file(s) that were checked out ▪ revert: undoing any changes to a file(s) that were checked out ▪ update: downloading the latest versions of all files that have been recently committed by other users
- 8. MERGING AND CONFLICTS ▪ Merge: Two sets of changes applied at same time to same files ▪ happens when two users check out same file(s), both change it, and: ▪ both commit, or ▪ one changes it and commits; the other changes it and does an update ▪ Conflict: when the system is unable to reconcile merged changes ▪ resolve: user intervention to repair a conflict. Possible ways: ▪ combining the changes manually in some way ▪ selecting one change in favor of the other ▪ reverting both changes (less likely)
- 9. SUBVERSION SVN ▪ Centralized version control systems. ▪ based on the idea that there is a single “central” copy of your project somewhere (probably on a server). ▪ programmers will “commit” their changes to this central copy. ▪ automatically update the contents of any files that were changed. ▪ Programmers no longer have to keep many copies of files on their hard drives manually.
- 10. DISADVANTAGES OF SVN ▪ The repository is centrally stored on a server. ▪ You need to be online to access. ▪ Performance is slow.
- 11. CENTRALIZED AND DISTRIBUTED VCS
- 12. VERSION CONTROL SYSTEM Version Control System VCS Centralized VCS Subversion Distributed VCS Git
- 13. ▪ Linus Torvalds, 2005 ▪ Came out of Linux development community ▪ Initial goals: free and open . Speed Support for non-linear development (thousands of parallel branches) Fully distributed Able to handle large projects like Linux efficiently
- 14. ADVANTAGES OF GIT ▪ Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server. ▪ Committing new changesets can be done locally without anyone else seeing them. ▪ Everything but pushing and pulling can be done without an internet connection. ▪ Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.
- 15. DISADVANTAGES OF GIT ▪ There are only two major inherent disadvantages to using a distributed system: ▪ If your project contains many large, binary files that cannot be easily compressed, the space needed to store all versions of these files can accumulate quickly. ▪ If your project has a very long history (50,000 changesets or more), downloading the entire history can take an impractical amount of time and disk space. ▪ The authors and contributors of modern distributed version control systems are working on solving these problems, but at the moment, no bundled, built-in features solve them.
- 16. WORKING WITH GIT ▪ Command line interface ▪ • Official Git Site —http://git-scm.com/
- 17. THANKS A LOT Ahmed Shawky Ali El-faky
Editor's Notes
- #3: no programmer is perfect, and sometimes, we make mistakes. If you make a change to a file, save it, compile it, and find out that something went wrong, it’s often helpful to be able to go back to the old version or to get a report of what we actually changed, in order to focus on what we may have done wrong.
- #12: The main difference between centralized and distributed version control is the number of repositories. In centralized version control, there is just one repository, and in distributed version control, there are multiple repositories. Here are pictures of the typical arrangements.
- #15: The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems: Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server. Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once. Everything but pushing and pulling can be done without an internet connection. So you can work on a plan, and you won’t be forced to commit sever Since each proal bugfixes as one big changeset. grammer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.
- #16: To be quite honest, there are almost no disadvantages to using a distributed version control system over a centralized one. Distributed systems do not prevent you from having a single “central” repository, they just provide more options on top of that. There are only two major inherent disadvantages to using a distributed system: If your project contains many large, binary files that cannot be easily compressed, the space needed to store all versions of these files can accumulate quickly. If your project has a very long history (50,000 changesets or more), downloading the entire history can take an impractical amount of time and disk space. The authors and contributors of modern distributed version control systems are working on solving these problems, but at the moment, no bundled, built-in features solve them.