On Thu, 08 Mar 2007, Folker Schamel wrote:
> > On Tue, 27 Feb 2007, Folker Schamel wrote:
> >>> On 2/26/07, *Justin Johnson* <email@example.com
> >>> <mailto:firstname.lastname@example.org>> wrote:
> >>> What information is available on what this merge tracking will include?
> >> Just for curiosity:
> >> (For all our use cases, the features of svnmerge.py are fine.)
> >> When merging something from branch A -> B,
> >> will merge respect already merged changes B -> A?
> >> (Like svnmerge.py --bidirectional.)
> >> Will merge respect already merged changes A -> X -> B or B -> X -> A?
> >> (Not supported by svnmerge.py.)
> > The specs can be found here:
> > http://subversion.tigris.org/merge-tracking/
> > If you can't determine the answer from reading the specs, let us know.
> Yes, I know these documents.
> I don't find the particular location again, but I think I found some
> implementation note indicating that "B -> A" handled.
> But I didn't find a note dealing with the other cases "A -> X -> B"
> and "B -> X -> A", so I suppose they are not handled, is this correct?
Great! I'm glad you're already familiar with the documents. Where in
the documents would you expect to find this information? (I'd like to
know where to clarify them.)
"A -> X -> B" is supported. Merge info is recorded on X for A when
merging A into X. When merging that same change for X into B, we
record both the merge info for the merge operation itself, plus merge
in the merge info from the original merge (from A -> X).
1. Run 'X$ svn merge -c 37 A', creating r50.
2. X now has merge info of "A:37".
3. Run 'B$ svn merge -c 50 X', creating r51.
4. B now has merge info of "A:37\nX:50".
Attempts to merge either r37 of A or r50 of X into B will be no-ops,
since B knows that those change sets have already been merged.
I don't follow how you want your "B -> X -> A" case to fit in here.
Received on Thu Mar 8 23:37:44 2007
- application/pgp-signature attachment: stored