This yields unnecessary and confusing conflicts.
if we include those synched revisions, then we merge back changes that already exist in.Even worse, we might have carelessly committed unrelated changes as part of the merge (it happens) so those changes would also be excluded. If we exclude the revisions that were merged from trunk, then we also exclude any work we did to resolve conflicts as part of those merges.When you eventually merge your branch back to trunk, that is called a reflective (or cyclic) merge. During the development process you regularly merge all new changes from trunk to your branch so that the branch stays in "synch" with the work occurring on trunk. Suppose you are working on a feature branch copied from your trunk. If it finds a path with explicit mergeinfo which has a subtree with equivalent explicit mergeinfo, then the subtree's mergeinfo is elided (removed). Once a merge is completed, Subversion walks the working copy tree rooted at the merge target. This consolidation process is called elision. It simply means the state of this path is as if nothing was ever merged into it.Īt the end of every merge Subversion tries to "consolidate" any redundant subtree mergeinfo. When a path inherits mergeinfo, it does so only from its nearest parent with explicit mergeinfo.Įmpty mergeinfo is a svn:mergeinfo property which has the empty string as a value. Only if no inheritable mergeinfo is found in the repository can we finally say the path has no mergeinfo whatsoever. If it reaches the top of the working copy and can't find such a parent, it will then ask the repository about any other parent paths, going as far as the root of the repository if necessary. When determining the inherited mergeinfo on a path with no explicit mergeinfo, Subversion will first crawl as far up the working copy as it can looking for a parent with explicit mergeinfo. The concept of "nearest parent" is not limited to the working copy. If a path doesn't have explicit mergeinfo it can still have inherited mergeinfo if it has a parent (or grandparent, or great-grandparent, etc.) with explicit mergeinfo. reverse merging a change from a path's own history.the merge source is from a different repository from the merge target.when using the -ignore-ancestry option.There are a few cases where a merge won't create or modify mergeinfo: when merging with incomplete represenation of repository (shallow working copy, switched subtrees, or because of authorization restrictions that prevent parts of a tree from being checked out).This is regarded as defficiency of Subversion and may be fixed we merged from a file in trunk to a file in our branch, creating mergeinfo on that file). when a merge target has some subtree that was previously a merge target itself (e.g.Normally mergeinfo is set only on the merge target. When a path has the mergeinfo property set on it, that path is said to have explicit mergeinfo. Mergeinfo the versioned property svn:mergeinfo, is the history of merges made into a given file or directory.
0 kommentar(er)
