On 6/7/07, Daniel Rall <dlr@collab.net> wrote:
> For an illustration of this problem, see merge (f) in this diagram:
> http://subclipse.tigris.org/files/documents/906/37977/repos.png
>
> The corresponding repository is available here:
> http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=8590&expandFolder=8590&folderID=8590
>
> From notes/merge-tracking.txt:
> * Account for reflected revisions when performing cyclic merges. For
> example: trunk is branched, then modified, and the branch is brought
> up to date with trunk, then the branch is modified, then the branch
> is merged to the trunk. To avoid repeated merging of changes to
> trunk, only the modification to the branch should be applied to
> trunk. (dlr)
>
> * Need an API which can refine the requested merge range from the
> branch based on a) what changes the merge from the branch already
> represents on trunk and b) what branch revisions were merges from
> trunk to the branch (which should be avoided, to skip replaying
> changes back to trunk which were made on trunk).
>
> I've got a patch (attached) will implements (a), filtering of
> reflected revisions. However, Mark Phippard has pointed out that (b),
> while it potentially causes repeated merges to occur, may be necessary
> to handle other local mods or conflict resolution which occurred after
> a merge.
>
> So, how do we handle this? Seems like we're stuck with a potential
> re-merging of an existing set of changes, which is a large part of
> what merge tracking is attempting to avoid.
This is one of the reasons i told you we would eventually need to know
which changes were the results of merges and where were modifies ;)
Let me answer this by stating some original design goals and
philosophy of how to get to where you want to be
The initial merge tracking implementation was not meant to handle
repeated bidirectional merging, at least, as designed.
It was designed to allow cherry picks, and mainly for maintaining
feature branches that were mostly one way merges, with the very
occasional merge in the other direction and then branch death :).
For these cases, it works out fine.
For more complex cyclical merge patterns, you really can't use what
we've got. Trying to work around these cases, or build algorithms
that handle them, is just going to lead you into 20 years of edge
cases that made people come up with changeset dags in the first place.
At the base of what we are trying to do is to try to discover which
subversion changesets exist on what branches, and which are there
because of merges.
This is fundamentally what distributed vcsens do, through having a
changeset DAG.
For these, a regular merge is simply discovering which changesets are
in one changeset graph but not the other (usually using common
ancestor algorithms, and ignoring the merge changesets since they
don't contribute anything).
Once you discover this, you merge in the changesets, and make a new
changeset whose two parents (in the graph) are the node whose
changesets you merged, and the old parent changeset for the tree.
(They also usually mark merged changesets as merge changests on the
branch they were merged to, so you can differentiate easily. Even
more advanced ones annotate the changeset dag edges with information
about cherry picks).
Subversion does not have a changeset graph.
We are effectively trying to emulate this by marking which files and
dirs have which changesets in them, trying to create something
resembling per-file and directory changeset graphs out of nothingness.
Doing so destroys the nice graph algorithms for merging you could
otherwise easily use :)
This is the problem you are hitting. Trying to come up with good ways
to tell which things go where.
Basically I would simply suggest you punt on the repeated conflicts
this may bring sometimes for 1.5, and put it as a "merge tracking for
2.0" .
You guys are doing a lot of work to emulate what are normally simple
graph algorithms. If I had believed you wanted all this in 1.5, I
would have cautioned you against it.
The original goal was to provide much the same functionality as
svnmerge.py on a per-file basis.
We can do that.
svnmerge.py does not handle this any better than we do
I would strongly urge you not to try to extend the current design past that.
It was simply meant to cover our bases.
(Note that it is possible to migrate the existing INFO to an explicit
changeset dag. The API would need to be reworked a little, but not
much)
If you really really wanted to, you could implement a changeset dag on
top of what we have now, for 1.6, and use that to get the rest of the
cases.
I would certainly recommend that over trying to walk and collect
billions of pieces of history in an attempt to recreate one on the fly
every time someone does a merge :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 8 20:38:40 2007
