If we had done a regular cloning, the new commit would have a parent that actually exist in the original repository, and which is in fact its HEAD. This is what allows a GeoGig repository to communicate with other repositories and push and pull commits and data, knowing when is it possible to push and when a cloned repository is outdated and its changes cannot be pushed without risking losing data. The parent property links a commit to the one (or several ones if it is a merge commit) that it derives from. Here you can see the two histories, with the corresponding abbreviated IDs of their commits. We will go back to the first example with just two commits. Let’s see why additional information is needed to keep the link between the original and the partially cloned repository. Please review the corresponding chapter in case you need to refresh those concepts. The explanations that follow assume that you understand the structure of a GeoGig repository and you are familiar with the concepts introduced in the Introduction section, since they are basically an extension of those ideas. However, since interaction is important, a partial clone has to keep track of commits in the original repository, because otherwise, it wouldn’t be able to interact with it. If your cloned repository was to be used just by itself and never had any interaction with the original repository from where it originates or with other cloned repositories (whether partial or complete), then a partial clone could be created, only creating new commits that resulted in a partial repository. Since commit 3 modifies a feature that does not exist in the sparse clone, it cannot be applied, and it is replaced by 3’, which just contains the changes that affect the feature that is available. The original commit (3) changed both features that were in the database after commit 2, but in the sparse clone, only one of those features is found, since the other one was not added, as it falls outside the are of interest. In this case, the original commit could not be applied, and it also has to be modified. The third one (3) is replaced by a new commit (3’) that just modifies the only feature in the cloned repository. The second commit (2) is not applied at all, since none of the changes it introduces affect the cloned repository, so it is skipped. In the cloned repo, the first commit (1) is replaced by a new one (1’) that just adds one of the features. Numbers indicate the commits that affect each feature. The picture below depicts the original and sparse clone for this case. The second one adds a new feature outside that bounding box, and finally the third one modifies all of the features. The first one adds two features, with only one of them being within the filter bounding box. Let’s suppose a different history in the original repository, this time with three commits. These commits will not be added to the cloned repository. Usually, the case will not be as simple as in the example above, and some commits might not affect any of the features in the area of interest defined by the filter. The number of commits doesn’t have to be identical in both the original and the sparse clone. In the cloned repository, each commit is replaced by a new one that just adds the feature that falls in the filtered area. Both of them add two new features and in each case, only one of those features falls within a given region, which is the one used to define a filter and create a shallow clone. The history of the original repository just has two commits. The number in each feature indicates the commit in which that feature was added.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |