The actual repository is housed inside of the. Git is able to read the file system and make comparisons to the actual repository, to determine the state of the files in the working folder.įigure 4 shows an example of a Git repository and working folder layout. Since Git pays attention to the file system and runs most commands locally, there is no need to store connection and state information about a folder in every folder. svn folders houses the necessary information for a Subversion client to know about the remote server, branch, and folder. svn folder for every folder that it retrieves from the remote repository. git FolderĪ Subversion checkout creates a hidden. Git can connect to the configured remotes at any time and there are only a few commands specifically for interacting with remote repositories.
#GITX BUG LIST HOW TO#
A remote is a set of configuration details that tells Git where the remote repository is, how to access it, and what the most recently known state of the remote repository is (see Figure 3). With Git, however, it is possible to configure multiple connections to multiple remote repositories. A Subversion checkout can point to one and only one repository, and all work is done against that repository. This tells the Subversion client where the server is, how to access it, and the most recent state of the repository that was pulled down to the local computer. When you do a checkout from a Subversion repository, information about the server is stored in the local file system. From a Subversion Repository to Git Remotes Git still supports the use of a shared, central server, but one is not strictly needed. In a peer-to-peer set up, such as this, commits are transferred directly between the users, instead of through a centralized server. !( 2.tiff) From Client-server to Peer-to-peerĪside from working against your local repository, Git provides the ability to connect to any of a number of Remote Git repositories, as shown in Figure 2. They can push changes to other users directly or let others grab the changes themselves. At that point, though, the user does not have to push their changes to a central server.
It is only when the user is ready to share their work that they need to think about any repositories that are not on their computer. Most actions taken against the repository are done locally including checking out files to work on, making changes, and committing those files. Instead, users work against a local repository as shown in Figure 2, not one that is stored on a server. In contrast to Subversion and centralized version-control systems, distributed systems do not require a central server-though one can be used. Figure 1 shows this classic model of source control with a centralized server and many users working against the repository on it. This model provides collaboration by having everyone work against the same server, with all of their work being visible to everyone else upon commit. Users who wish to work against that repository will bring a copy of what they need down to their local computer, make the necessary changes, and then commit the changes directly to the repository on the server. Subversion-among many other popular source-control systems such as CVS and Team Foundation Server-solves these problems using a centralized repository model. Having a basic understanding of where and how Subversion and Git differ will offer insights into working with Git and why certain actions and commands are necessary. While there are a number of ideas that transfer from Subversion to Git, there are also a number of ideas in Git that will not have an equivalent. It is also necessary to understand the differences and to look at some of the features that Git provides, for which Subversion has no equivalent.
However, understanding the similarities alone will not be sufficient for learning Git. Understanding how these systems are similar can be important for those with experience using Subversion who want to learn Git. There are still other similarities, as well. They both support branching, merging, and working with files without locking them. They are both popular and are open source, proving integration points for other development-related tools. They are both source-control systems that work on nearly every modern development platform. There are some similarities between Subversion and Git.
0 kommentar(er)
