The amount of time it takes to resolve conflicts is usuallyįar less than the time lost by a locking system. The same files, it turns out that most of their concurrentĬhanges don't overlap at all conflicts are infrequent. The copy-modify-merge model may sound a bit chaotic, but Manually resolved the overlapping changes-perhaps afterĪ discussion with Sally-he can safely save the Resolve conflicts only humans are capable of understandingĪnd making the necessary intelligent choices. Is somehow flagged as being in a state of conflict: he'll beĪble to see both sets of conflicting changes, and manuallyĬhoose between them. Repository changes into his working copy, his copy of file A When Harry asks his client to merge the latest With Harry's changes? What then? This situation is called aĪ problem. Figure 1.4, “The copy-modify-merge solution” and Figure 1.5, “The copy-modify-merge solution (continued)” show this Saves his working copy back to the repository. His own so once he has both sets of changes integrated, he Chances are that Sally's changes don't overlap with Later, the repository informs him that his file A isĪ in the repository has somehow changed since he last copiedĪny new changes from the repository into his working copy ofįile A. They work concurrently, and make changes to the Working copies of the same project, copied from the Responsible for making it happen correctly. The version control system oftenĪssists with the merging, but ultimately a human being is Finally, the private copies are merged together intoĪ new, final version. Simultaneously and independently, modifying their privateĬopies. Of the repository's files and directories. In this model, each user's clientĬontacts the project repository and creates a personal Subversion, CVS, and many other version control systemsĪlternative to locking. Insulated task, and thus not bother discussing their Imagine that by locking files, each is beginning a safe, Prevent the problem-yet it somehow provided a false Semantically incompatible? Suddenly A and B don't work But what if A andī depend on one another, and the changes made to each are Suppose Harry locks and edits file A, while Sally There's no need for them to take turns in this They could easilyĮdit the file simultaneously, and no great harm wouldĬome, assuming the changes were properly merged together. What if Harry is editing the beginning of a text file,Īnd Sally simply wants to edit the end of the same file? The situation ends up causing a lot of unnecessary delay Sally has to get an administrator to release Harry's lock. Meanwhile, because Sally is still waiting to edit the file, Sometimes Harry will lock a file and then forget about it. Least missing from the latest version of the file-and
Harry's work is still effectively lost-or at Of the file, because she never saw Harry's changes to begin Won't be present in Sally's newer version System remembers every change), any changes Harry made Harry's version of the file won't be lost forever (because the Overwrite them with her own new version of the file. Possible that (a few moments later) Sally could accidentally Harry saves his changes to the repository first, then it's They eachĭecide to edit the same repository file at the same time.
Suppose we have two co-workers, Harry and Sally. Information, but prevent them from accidentally stepping onĮach other's feet? It's all too easy for users toĪccidentally overwrite each other's changes in theĬonsider the scenario shown in Figure 1.2, “The problem to avoid”. All version control systems have to solve the sameįundamental problem: how will the system allow users to share
0 kommentar(er)
