Reconstructing thoughts about implicit mergeinfo

[CC:ING DEVSUBVERSION]

DLR, MARKPHIP:

AS I STARTED THINKING ABOUT THE IMPLICIT MERGEINFO SITUATION
TODAY (ISSUE
#2875), I REALIZED A BIG HOLE IN MY PROPOSAL FROM LAST WEEK.
 (AND THIS
MIGHT BE EXACTLY WHAT YOU GUYS WERE TRYING TO EXPRESS ON OUR
PHONE CALL
ABOUT THE TOPIC.)  THE PROBLEM IS THIS:  IF WE HAVE A FLAG
ON SOME OBJECT'S
SVN:MERGEINFO PROPERTY THAT SAYS, "ALL MY IMPLICIT
MERGEINFO IS NOW
EXPLICITLY RECORDED", THAT INFORMATION IS OUT OF THE
DATE THE MINUTE WE
COMMIT CHANGES TO THAT OBJECT.  I MEAN, WE'VE EXTENDED THE
HISTORY OF THE
OBJECT, AND THE IMPLICIT MERGEINFO IS DEFINED AS "THE
NATURAL VERSION
HISTORY OF THE OBJECT".  THAT'S NO GOOD.

THIS CAUSED ME TO TRY TO RECONSTRUCT OUR THOUGHTS FROM THE
CALL ABOUT THIS
LAST WEEK, BUT MY MEMORY BEING IMPERFECT, I ULTIMATELY
FAILED.  I MEAN, I
MADE SOME NOTES ABOUT SPECIFIC SCENARIOS WE DISCUSSED, BUT
THEY DON'T COVER
EVERYTHING.

SO I STARTED WITH A BASIC BIT OF DEFINITION STUFFS, LIKE
SO:

   EVERY NODE'S ANCESTRY SET CONSISTS TO TWO THINGS:

      1.  ITS NATURAL VERSION HISTORY (CHANGES MADE AND
COMMITTED
          DIRECTLY TO THE OBJECT OR ITS CHILDREN), AND
      2.  MERGES OF CHANGES MADE TO ALTERNATE LINES OF
HISTORY.

   THE FIRST OF THESE WE CALL "IMPLICIT
MERGEINFO"; THE LATTER "EXPLICIT
   MERGEINFO".  EXPLICIT MERGEINFO CAN BE STORED
LITERALLY ON A NODE VIA
   THE SVN:MERGEINFO PROPERTY, OR CAN BE INHERITED FROM ITS
PARENT
   DIRECTORY.

AND THEN NATURALLY I ADDED THE LINE, "THESE TWO SOURCES
OF ANCESTRY DATA
SHOULD NOT OVERLAP".  THIS BROUGHT ME BACK ALL THE WAY
TO THE GROUND ZERO ON
THIS PROBLEM.

AT THIS POINT, I'M STRONGLY CONSIDERING GOING WITH THE NAIVE
APPROACH:

   1. ALWAYS ADD IMPLICIT MERGEINFO TO THE EXPLICIT WHEN
      CALCULATIN', AND
   2. ALWAYS REMOVE IMPLICIT MERGEINFO FROM THE RESULTS
BEFORE
      STORIN'.

THE FEAR HERE IS THAT ASKING THE SERVER FOR IMPLICIT
MERGEINFO WILL BE
COSTLY.  AND THAT'S A REAL ISSUE, REGARDLESS OF SERVER
PEDIGREE.  I REALIZE
NOW THAT HAD WE A FILESYSTEM TABLE THAT MAPPED NODE_ID ->
FIRST_NODE_REV_ID
(BASICALLY, FOR ANY LINE OF HISTORY, WHAT WAS THE FIRST NODE
REVISION IN
THAT LINE OF HISTORY), WE COULD *VASTLY* IMPROVE THE SPEED
OF THIS OPERATION
TO THE ULTIMATE BENEFIT OF ALL.  BUT I DUNNO IF ADDING SUCH
AN INDEX IS
WITHIN SCOPE FOR 1.5 (IT COULD JUST AS EASILY BE ADDED
LATER).

IF I DON'T TAKE THE NAIVE APPROACH, THEN I NEED TO FIND A
SOLUTION THAT
WORKS BETTER THAN MY
"IMPLICIT-MERGEINFO-IS-EXPLICITLY-REPRESENTED"
FLAG,
BECAUSE I NOW SEE THE FOLLY OF THAT.

THOUGHTS?  (AND SORRY IF YOU GUYS SAW THIS COMING ALL ALONG
AND I JUST
MISSED IT.)

-- 
C. MICHAEL PILATO <CMPILATOCOLLAB.NET>
COLLABNET   <>   WWW.COLLAB.NET   <>  
DISTRIBUTED DEVELOPMENT ON DEMAND

On 11/5/07, C. Michael Pilato <cmpilatocollab.net> wrote:
> [Cc:ing devsubversion]
>
> dlr, markphip:
>
> As I started thinking about the implicit mergeinfo
situation today (issue
> #2875), I realized a big hole in my proposal from last
week.  (And this
> might be exactly what you guys were trying to express
on our phone call
> about the topic.)  The problem is this:  if we have a
flag on some object's
> svn:mergeinfo property that says, "All my implicit
mergeinfo is now
> explicitly recorded", that information is out of
the date the minute we
> commit changes to that object.  I mean, we've extended
the history of the
> object, and the implicit mergeinfo is defined as
"the natural version
> history of the object".  That's no good.
>
> This caused me to try to reconstruct our thoughts from
the call about this
> last week, but my memory being imperfect, I ultimately
failed.  I mean, I
> made some notes about specific scenarios we discussed,
but they don't cover
> everything.
>
> So I started with a basic bit of definition stuffs,
like so:
>
>    Every node's ancestry set consists to two things:
>
>       1.  its natural version history (changes made and
committed
>           directly to the object or its children), and
>       2.  merges of changes made to alternate lines of
history.
>
>    The first of these we call "implicit
mergeinfo"; the latter "explicit
>    mergeinfo".  Explicit mergeinfo can be stored
literally on a node via
>    the svn:mergeinfo property, or can be inherited from
its parent
>    directory.
>
> And then naturally I added the line, "These two
sources of ancestry data
> should not overlap".  This brought me back all the
way to the ground zero on
> this problem.
>
> At this point, I'm strongly considering going with the
naive approach:
>
>    1. always add implicit mergeinfo to the explicit
when
>       calculatin', and
>    2. always remove implicit mergeinfo from the results
before
>       storin'.
>
> The fear here is that asking the server for implicit
mergeinfo will be
> costly.  And that's a real issue, regardless of server
pedigree.  I realize
> now that had we a filesystem table that mapped node_id
-> first_node_rev_id
> (basically, for any line of history, what was the first
node revision in
> that line of history), we could *vastly* improve the
speed of this operation
> to the ultimate benefit of all.  But I dunno if adding
such an index is
> within scope for 1.5 (it could just as easily be added
later).
>
> If I don't take the naive approach, then I need to find
a solution that
> works better than my
"implicit-mergeinfo-is-explicitly-represented"
flag,
> because I now see the folly of that.
>
> Thoughts?  (And sorry if you guys saw this coming all
along and I just
> missed it.)

I am not sure it is as bad as you think.  The implicit
mergeinfo for a
path should essentially represent the history of the item
when it was
copied.  If you copy /trunk  r100 to make a branch then
the implicit
mergeinfo for the branch is trunk from its creation to r100.
 Although
currently I believe you also get whatever is in the
mergeinfo property
for trunk which would include information about other
branches that
have been merged into trunk.

It sounded like you felt like you could ask the repository
for this
information when needed rather than require it to live in
the
mergeinfo property.  That being said, we also agreed that at
some
point this information does need to be stored in the
property.  It
seemed like we had a couple of ideas here:

1)  Do it the first time the mergeinfo is needed.  i guess
this would
happen when you first merged into the location?

2)  Do it the first time the implicit mergeinfo needs to be
modified.
This would be a reverse merge that removed some of the
revisions that
were originally copied into the path.  This would require
some kind of
special indicator in the property that told you whether this
has
happened or not.

The key is that we have to support the scenario of #2.  In
theory the
implicit mergeinfo for an item could be changed.  Dan's
example was
good.  Suppose you make a branch off trunk and start working
on it.
Now, some big bug is discovered in trunk so a reverse merge
is done on
trunk and all active branches to remove that commit.  When
this is
done, that implicit mergeinfo on the branch now needs to
reflect that
the revision it inherited from trunk has been explicitly
removed.

I am not sure this helps, but it is a dump of my relevant
memory.

-- 
Thanks

Mark Phippard
http://markphip.blogspo
t.com/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

MARK PHIPPARD WROTE:
> ON 11/5/07, C. MICHAEL PILATO <CMPILATOCOLLAB.NET> WROTE:
>> [CC:ING DEVSUBVERSION]
>>
>> DLR, MARKPHIP:
>>
>> AS I STARTED THINKING ABOUT THE IMPLICIT MERGEINFO
SITUATION TODAY (ISSUE
>> #2875), I REALIZED A BIG HOLE IN MY PROPOSAL FROM
LAST WEEK.  (AND THIS
>> MIGHT BE EXACTLY WHAT YOU GUYS WERE TRYING TO
EXPRESS ON OUR PHONE CALL
>> ABOUT THE TOPIC.)  THE PROBLEM IS THIS:  IF WE HAVE
A FLAG ON SOME OBJECT'S
>> SVN:MERGEINFO PROPERTY THAT SAYS, "ALL MY
IMPLICIT MERGEINFO IS NOW
>> EXPLICITLY RECORDED", THAT INFORMATION IS OUT
OF THE DATE THE MINUTE WE
>> COMMIT CHANGES TO THAT OBJECT.  I MEAN, WE'VE
EXTENDED THE HISTORY OF THE
>> OBJECT, AND THE IMPLICIT MERGEINFO IS DEFINED AS
"THE NATURAL VERSION
>> HISTORY OF THE OBJECT".  THAT'S NO GOOD.
>>
>> THIS CAUSED ME TO TRY TO RECONSTRUCT OUR THOUGHTS
FROM THE CALL ABOUT THIS
>> LAST WEEK, BUT MY MEMORY BEING IMPERFECT, I
ULTIMATELY FAILED.  I MEAN, I
>> MADE SOME NOTES ABOUT SPECIFIC SCENARIOS WE
DISCUSSED, BUT THEY DON'T COVER
>> EVERYTHING.
>>
>> SO I STARTED WITH A BASIC BIT OF DEFINITION STUFFS,
LIKE SO:
>>
>>    EVERY NODE'S ANCESTRY SET CONSISTS TO TWO
THINGS:
>>
>>       1.  ITS NATURAL VERSION HISTORY (CHANGES MADE
AND COMMITTED
>>           DIRECTLY TO THE OBJECT OR ITS CHILDREN),
AND
>>       2.  MERGES OF CHANGES MADE TO ALTERNATE LINES
OF HISTORY.
>>
>>    THE FIRST OF THESE WE CALL "IMPLICIT
MERGEINFO"; THE LATTER "EXPLICIT
>>    MERGEINFO".  EXPLICIT MERGEINFO CAN BE
STORED LITERALLY ON A NODE VIA
>>    THE SVN:MERGEINFO PROPERTY, OR CAN BE INHERITED
FROM ITS PARENT
>>    DIRECTORY.
>>
>> AND THEN NATURALLY I ADDED THE LINE, "THESE
TWO SOURCES OF ANCESTRY DATA
>> SHOULD NOT OVERLAP".  THIS BROUGHT ME BACK ALL
THE WAY TO THE GROUND ZERO ON
>> THIS PROBLEM.
>>
>> AT THIS POINT, I'M STRONGLY CONSIDERING GOING WITH
THE NAIVE APPROACH:
>>
>>    1. ALWAYS ADD IMPLICIT MERGEINFO TO THE EXPLICIT
WHEN
>>       CALCULATIN', AND
>>    2. ALWAYS REMOVE IMPLICIT MERGEINFO FROM THE
RESULTS BEFORE
>>       STORIN'.
>>
>> THE FEAR HERE IS THAT ASKING THE SERVER FOR
IMPLICIT MERGEINFO WILL BE
>> COSTLY.  AND THAT'S A REAL ISSUE, REGARDLESS OF
SERVER PEDIGREE.  I REALIZE
>> NOW THAT HAD WE A FILESYSTEM TABLE THAT MAPPED
NODE_ID -> FIRST_NODE_REV_ID
>> (BASICALLY, FOR ANY LINE OF HISTORY, WHAT WAS THE
FIRST NODE REVISION IN
>> THAT LINE OF HISTORY), WE COULD *VASTLY* IMPROVE
THE SPEED OF THIS OPERATION
>> TO THE ULTIMATE BENEFIT OF ALL.  BUT I DUNNO IF
ADDING SUCH AN INDEX IS
>> WITHIN SCOPE FOR 1.5 (IT COULD JUST AS EASILY BE
ADDED LATER).
>>
>> IF I DON'T TAKE THE NAIVE APPROACH, THEN I NEED TO
FIND A SOLUTION THAT
>> WORKS BETTER THAN MY
"IMPLICIT-MERGEINFO-IS-EXPLICITLY-REPRESENTED"
FLAG,
>> BECAUSE I NOW SEE THE FOLLY OF THAT.
>>
>> THOUGHTS?  (AND SORRY IF YOU GUYS SAW THIS COMING
ALL ALONG AND I JUST
>> MISSED IT.)
> 
> I AM NOT SURE IT IS AS BAD AS YOU THINK.  THE IMPLICIT
MERGEINFO FOR A
> PATH SHOULD ESSENTIALLY REPRESENT THE HISTORY OF THE
ITEM WHEN IT WAS
> COPIED.  IF YOU COPY /TRUNK  R100 TO MAKE A BRANCH THEN
THE IMPLICIT
> MERGEINFO FOR THE BRANCH IS TRUNK FROM ITS CREATION TO
R100.  ALTHOUGH
> CURRENTLY I BELIEVE YOU ALSO GET WHATEVER IS IN THE
MERGEINFO PROPERTY
> FOR TRUNK WHICH WOULD INCLUDE INFORMATION ABOUT OTHER
BRANCHES THAT
> HAVE BEEN MERGED INTO TRUNK.

OKAY, YOU'RE USING A DIFFERENT DEFINITION OF "IMPLICIT
MERGEINFO" THAN I AM.
 AND TO BE HONEST, I'M NOT SURE I UNDERSTAND THE REASONING
FOR YOURS.  WHAT
IS SIGNIFICANT ABOUT ONLY THE SUBSET OF AN OBJECT'S NATURAL
VERSION HISTORY
THAT OCCURRED PRIOR TO ITS MOST RECENT COPY?

> IT SOUNDED LIKE YOU FELT LIKE YOU COULD ASK THE
REPOSITORY FOR THIS
> INFORMATION WHEN NEEDED RATHER THAN REQUIRE IT TO LIVE
IN THE
> MERGEINFO PROPERTY.  THAT BEING SAID, WE ALSO AGREED
THAT AT SOME
> POINT THIS INFORMATION DOES NEED TO BE STORED IN THE
PROPERTY.

WELL, FOR MY PART, I AGREED TO THIS BECAUSE I WAS
DELUSIONAL, APPARENTLY
DEFINING THE TERM DIFFERENTLY THAN YOU, AND YET STILL
INCORRECT ABOUT THE
IMPLICATIONS.  

> IT SEEMED LIKE WE HAD A COUPLE OF IDEAS HERE:
> 
> 1)  DO IT THE FIRST TIME THE MERGEINFO IS NEEDED.  I
GUESS THIS WOULD
> HAPPEN WHEN YOU FIRST MERGED INTO THE LOCATION?
> 
> 2)  DO IT THE FIRST TIME THE IMPLICIT MERGEINFO NEEDS
TO BE MODIFIED.
> THIS WOULD BE A REVERSE MERGE THAT REMOVED SOME OF THE
REVISIONS THAT
> WERE ORIGINALLY COPIED INTO THE PATH.  THIS WOULD
REQUIRE SOME KIND OF
> SPECIAL INDICATOR IN THE PROPERTY THAT TOLD YOU WHETHER
THIS HAS
> HAPPENED OR NOT.
> 
> THE KEY IS THAT WE HAVE TO SUPPORT THE SCENARIO OF #2. 
IN THEORY THE
> IMPLICIT MERGEINFO FOR AN ITEM COULD BE CHANGED.  DAN'S
EXAMPLE WAS
> GOOD.  SUPPOSE YOU MAKE A BRANCH OFF TRUNK AND START
WORKING ON IT.
> NOW, SOME BIG BUG IS DISCOVERED IN TRUNK SO A REVERSE
MERGE IS DONE ON
> TRUNK AND ALL ACTIVE BRANCHES TO REMOVE THAT COMMIT. 
WHEN THIS IS
> DONE, THAT IMPLICIT MERGEINFO ON THE BRANCH NOW NEEDS
TO REFLECT THAT
> THE REVISION IT INHERITED FROM TRUNK HAS BEEN
EXPLICITLY REMOVED.

THIS LOGIC CONCERNS ME, AND RELATES TO A QUESTION I ASKED
PAUL YESTERDAY
ABOUT SVN:MERGEINFO ON A PATH HAVING REFERENCES TO MERGE
SOURCES FROM THE
SAME PATH.  SAY I HAVE A SINGLE BRANCH (TRUNK) THAT I'M
WORKING ON, AND NEED
TO UNDO A COMMITTED CHANGE.  I MERGE -C-N THE CHANGE.  NOW,
DO WE EXPECT
THAT THE MERGEINFO FOR TRUNK CONTAINS:

   /TRUNK:-N

?  I SAY "NO".  WHY DO I RATE A SPECIAL RECORD OF
AN UNDOING COMMIT, WHEN I
DON'T HAVE ANY SPECIAL RECORDS OF "DOING"
COMMITS?

(AND AGAIN, PERHAPS BECAUSE OF OUR DIFFERING DEFINITIONS OF
"IMPLICIT
MERGEINFO", I DON'T BELIEVE THE IMPLICIT CAN BE
CHANGED.)

I THINK THIS ALL BOILS DOWN TO SOME DIFFERENCES OF OPINION
ABOUT THE
SIGNIFICANCE OF A COPY OPERATION.  FOR SOME REASON, THE
DECISION WAS MADE TO
RECORD MERGE INFO DURING A NON-MERGE OPERATION (THE COPY). 
IF I UNDERSTOOD
THAT DECISION AND THE REASONS FOR IT, I THINK I'D BE BETTER
SUITED TO
UNDERSTAND THE REST OF THIS MESS.  THE ONLY THING I CAN
THINK OF AS A REASON
IS "SO WE KNOW WHAT OUR DEFAULT MERGE SOURCE SHOULD
BE" -- BUT MY RESPONSE
TO THAT IS "THAT'S SILLY, JUST QUERY THE HISTORY OF THE
OBJECT FOR THE SAME
(ACTUALLY, BETTER) INFO".

HELP?!

-- 
C. MICHAEL PILATO <CMPILATOCOLLAB.NET>
COLLABNET   <>   WWW.COLLAB.NET   <>  
DISTRIBUTED DEVELOPMENT ON DEMAND

On 11/6/07, C. Michael Pilato <cmpilatocollab.net> wrote:
> Mark Phippard wrote:
> > I am not sure it is as bad as you think.  The
implicit mergeinfo for a
> > path should essentially represent the history of
the item when it was
> > copied.  If you copy /trunk  r100 to make a branch then
the implicit
> > mergeinfo for the branch is trunk from its
creation to r100.  Although
> > currently I believe you also get whatever is in
the mergeinfo property
> > for trunk which would include information about
other branches that
> > have been merged into trunk.
>
> Okay, you're using a different definition of
"implicit mergeinfo" than I am.
>  And to be honest, I'm not sure I understand the
reasoning for yours.  What
> is significant about only the subset of an object's
natural version history
> that occurred prior to its most recent copy?

You have to take everything I say with a grain of salt
because since I
do not work down in the code I could use terms different
than Dan,
Paul etc do.  That being said, I view there are two kinds
of
mergeinfo:

implicit - this is created at the time a path is created. 
It is the
history of revisions and paths that initially make up the
item.

explicit - everything that is merged into the path after it
is created.

I am not taking into account the inheritance of mergeinfo or
anything
of that nature as I am not sure that changes these
definitions.  I
think that just adds some implementation details as to where
this come
from.

> > It sounded like you felt like you could ask the
repository for this
> > information when needed rather than require it to
live in the
> > mergeinfo property.  That being said, we also
agreed that at some
> > point this information does need to be stored in
the property.
>
> Well, for my part, I agreed to this because I was
delusional, apparently
> defining the term differently than you, and yet still
incorrect about the
> implications.  

Perhaps I need to see your definitions.

> > It seemed like we had a couple of ideas here:
> >
> > 1)  Do it the first time the mergeinfo is needed. 
i guess this would
> > happen when you first merged into the location?
> >
> > 2)  Do it the first time the implicit mergeinfo
needs to be modified.
> > This would be a reverse merge that removed some of
the revisions that
> > were originally copied into the path.  This would
require some kind of
> > special indicator in the property that told you
whether this has
> > happened or not.
> >
> > The key is that we have to support the scenario of
#2.  In theory the
> > implicit mergeinfo for an item could be changed. 
Dan's example was
> > good.  Suppose you make a branch off trunk and
start working on it.
> > Now, some big bug is discovered in trunk so a
reverse merge is done on
> > trunk and all active branches to remove that
commit.  When this is
> > done, that implicit mergeinfo on the branch now
needs to reflect that
> > the revision it inherited from trunk has been
explicitly removed.
>
> This logic concerns me, and relates to a question I
asked Paul yesterday
> about svn:mergeinfo on a path having references to
merge sources from the
> same path.  Say I have a single branch (trunk) that I'm
working on, and need
> to undo a committed change.  I merge -c-N the change. 
Now, do we expect
> that the mergeinfo for trunk contains:
>
>    /trunk:-N
>
> ?  I say "no".  Why do I rate a special
record of an undoing commit, when I
> don't have any special records of "doing"
commits?

I say "no" too.  If a path is created by copying
trunk at r100 you get
this mergeinfo:

/trunk:1-100

If you do a reverse merge of revision 90, the mergeinfo
should be
changed to this:

/trunk:1-89,91-100

The above is how I understand it to work today.  It is
possible things
have changed in the last few months, I have not been
watching the
property contents lately.  Getting back to the proposal, my
assumption
was that we would change this behavior so that when a path
is created
we do not create any mergeinfo.  Or we create something
special like:

/trunk: *

After a reverse merge if revision 90, I would expect the
mergeinfo to
become this:

/trunk:1-89,91-100

In other words, we now need to just rely on what is in the
property as
we have removed something that we originally got from
copying the
item.

> (And again, perhaps because of our differing
definitions of "implicit
> mergeinfo", I don't believe the implicit can be
changed.)
>
> I think this all boils down to some differences of
opinion about the
> significance of a copy operation.  For some reason, the
decision was made to
> record merge info during a non-merge operation (the
copy).  If I understood
> that decision and the reasons for it, I think I'd be
better suited to
> understand the rest of this mess.  The only thing I can
think of as a reason
> is "so we know what our default merge source
should be" -- but my response
> to that is "that's silly, just query the history
of the object for the same
> (actually, better) info".

This part confuses me, because to me it really sounds like
we are
saying the same thing.  I hope my examples shed some light
on this.
You say that the implicit cannot be changed.  That is not
true, a
reverse merge can remove things that were originally there
as part of
the implicit mergeinfo.  When that happens, we now need to
let our
logic know that the mergeinfo property is the canonical
source of
information and the repository history is no longer a
factor.

-- 
Thanks

Mark Phippard
http://markphip.blogspo
t.com/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

MARK PHIPPARD WROTE:
> YOU HAVE TO TAKE EVERYTHING I SAY WITH A GRAIN OF SALT
BECAUSE SINCE I
> DO NOT WORK DOWN IN THE CODE I COULD USE TERMS
DIFFERENT THAN DAN,
> PAUL ETC DO.  THAT BEING SAID, I VIEW THERE ARE TWO
KINDS OF
> MERGEINFO:
> 
> IMPLICIT - THIS IS CREATED AT THE TIME A PATH IS
CREATED.  IT IS THE
> HISTORY OF REVISIONS AND PATHS THAT INITIALLY MAKE UP
THE ITEM.
> 
> EXPLICIT - EVERYTHING THAT IS MERGED INTO THE PATH
AFTER IT IS CREATED.

YES, I UNDERSTAND YOUR DEFINITIONS.  I DON'T UNDERSTAND WHY
THOSE ARE THE
DEFINITIONS CHOSEN.

MY UNDERSTANDING OF THE WHOLE POINT OF MERGE TRACKING IS
THAT WE'RE TRYING
TO KEEP TRACK OF ALL THE SOURCES OF CHANGES MADE TO A GIVEN
DIRECTORY THAT
*ARE EXTERNAL TO* THE REGULAR OL' UPDATE-EDIT-COMMIT CYCLE. 
COPIES ARE
*NOT* EXTERNAL TO THAT CYCLE.  A COPY DOESN'T FEED DATA FROM
SOME OTHER
SOURCE INTO AN EXISTING OBJECT -- QUITE THE OPPOSITE.  SO I
DON'T UNDERSTAND
WHY 'SVN COPY TRUNK BRANCHES/MY-BRANCH' SHOULD RECORD
MERGEINFO ON
BRANCHES/MY-BRANCH.  THE INFORMATION THERE IS COMPLETELY
REDUNDANT WITH THE
INFORMATION ALREADY CONTAINED IN BRANCHES/MY-BRANCH'S
HISTORY.  IT DOESN'T
REPRESENT CHANGES BROUGHT INTO MY-BRANCH FROM SOME OTHER
SOURCE, BECAUSE
THAT SOURCE IS JUST MY-BRANCH ITSELF PRIOR TO SOME NAME
CHANGE (WHICH I
POSIT IS IRRELEVANT FROM THE STANDPOINT OF HISTORY
TRACKING).

> PERHAPS I NEED TO SEE YOUR DEFINITIONS.

I PROVIDED THEM IN MY ORIGINAL MAIL:

   EVERY NODE'S ANCESTRY SET CONSISTS TO TWO THINGS:

      1.  ITS NATURAL VERSION HISTORY (CHANGES MADE AND
COMMITTED
          DIRECTLY TO THE OBJECT OR ITS CHILDREN), AND
      2.  MERGES OF CHANGES MADE TO ALTERNATE LINES OF
HISTORY.

   THE FIRST OF THESE WE CALL "IMPLICIT
MERGEINFO"; THE LATTER "EXPLICIT
   MERGEINFO".  EXPLICIT MERGEINFO CAN BE STORED
LITERALLY ON A NODE VIA
   THE SVN:MERGEINFO PROPERTY, OR CAN BE INHERITED FROM ITS
PARENT
   DIRECTORY.

>> THIS LOGIC CONCERNS ME, AND RELATES TO A QUESTION I
ASKED PAUL YESTERDAY
>> ABOUT SVN:MERGEINFO ON A PATH HAVING REFERENCES TO
MERGE SOURCES FROM THE
>> SAME PATH.  SAY I HAVE A SINGLE BRANCH (TRUNK) THAT
I'M WORKING ON, AND NEED
>> TO UNDO A COMMITTED CHANGE.  I MERGE -C-N THE
CHANGE.  NOW, DO WE EXPECT
>> THAT THE MERGEINFO FOR TRUNK CONTAINS:
>>
>>    /TRUNK:-N
>>
>> ?  I SAY "NO".  WHY DO I RATE A SPECIAL
RECORD OF AN UNDOING COMMIT, WHEN I
>> DON'T HAVE ANY SPECIAL RECORDS OF "DOING"
COMMITS?
> 
> I SAY "NO" TOO.  IF A PATH IS CREATED BY
COPYING TRUNK AT R100 YOU GET
> THIS MERGEINFO:
> 
> /TRUNK:1-100
> 
> IF YOU DO A REVERSE MERGE OF REVISION 90, THE MERGEINFO
SHOULD BE
> CHANGED TO THIS:
> 
> /TRUNK:1-89,91-100

YOU CHANGED THE SCENARIO.  I DIDN'T SAY ANYTHING ABOUT A
COPY.  I'M TALKING
ABOUT SIMPLY USING MERGE TO UNDO A REVISION PREVIOUSLY MADE
ON A GIVEN LINE
OF HISTORY.  SHOULD WE RECORD THAT FACT OR NOT?

BUT LET'S LOOK AT YOUR EXAMPLE, INCORPORATING MINE INTO TO. 
WE HAVE A
TRUNK, AND WE HAVE A BRANCH 'FOO' CREATED FROM TRUNK100.  IN
R90 OF THE
TRUNK, SOMEONE COMMITTED A NASTY BUG.  IN R110, THEY
REVERSE-MERGED R90 AND
COMMITTED, EFFECTIVELY UNDOING THE BUG INTRODUCTION.

SO, FIRST THINGS FIRST.  WHEN THE REVERSE-MERGE OF R90 WAS
COMMITTED TO
TRUNK AS R110, DID IT INTRODUCE MERGEINFO *ON TRUNK ITSELF*
OF:

   /TRUNK:-90

THE ANSWER TO THIS QUESTION IS CRITICAL TO MY UNDERSTANDING
OF WHAT WE'RE
TRYING TO DO HERE; HAND-WAVING AROUND THIS IS NOT AN OPTION
FOR ME.

MOVING ON, USING MY DEFINITION OF IMPLICIT MERGEINFO (WHICH
IS A MISNOMER,
REALLY, AS IT HAS NOTHING TO DO WITH MERGING), WHEN I
CREATED THE BRANCH
'FOO' FROM TRUNK100, THERE WAS NO NEED TO RECORD ANY
MERGEINFO WHATSOEVER
YET.  I HAD NOT YET INTRODUCED CHANGES TO 'FOO' FROM AN
ALTERNATE LINE OF
HISTORY.  I HAD MERELY FORKED A SINGLE LINE OF HISTORY.

NOW I WISH TO MERGE THE BUGFIX FROM THE TRUNK.  THERE ARE A
FEW WAYS TO DO THIS.

FIRST, I COULD MERGE THE UNDOING REVISION COMMITTED IN
R110.

   $ SVN MERGE -C 110 HTTP://.../TRUNK TRUNK

TO ME, THIS NOW EARNS 'FOO' SOME MERGEINFO:

   /TRUNK:110

WHY?  BECAUSE THIS IS THE FIRST TIME IN THE HISTORY OF 'FOO'
THAT THE SOURCE
OF OUR CHANGES WAS SOME ALTERNATE LINE OF HISTORY (THE OTHER
TONG OF OUR
FORK FROM TRUNK).

ALTERNATIVELY, WE COULD REVERSE-MERGE R90 ONTO 'FOO' USING
TRUNK AS THE
SOURCE, FIXING THE BUG ON OUR BRANCH THE SAME WAY IT WAS
FIXED ON THE TRUNK.

   $ SVN MERGE -C -90 HTTP://.../TRUNK BRANCHES/FOO

BUT HERE'S WHERE I QUESTION WHAT HAPPENS.  SHOULD 'FOO' GET
MERGEINFO NOW?

   /TRUNK:-90

IN MY OPINION, THIS IS *EXACTLY THE SAME SCENARIO* AS WHEN
WE REVERSE-MERGED
R90 ON TRUNK ITSELF, AND THEREFORE SHOULD HAVE EXACTLY THE
SAME RESULTS.

FINALLY, WE COULD REVERSE-MERGE R90 USING 'FOO' AS THE
SOURCE.

   $ SVN MERGE -C -90 HTTP://.../BRANCHES/FOO BRANCHES/FOO

BUT MY MERGE SOURCE NORMALIZATION LOGIC WOULD INTERNALLY
REMAP THIS AS A
REVERSE-MERGE OF R90 USING TRUNK AS THE SOURCE, SO THIS
BECOMES THE SAME AS
THE PREVIOUS METHOD.

I'M TERRIBLY SORRY IF I'M OVERTHINKING (OR WORSE,
UNDERTHINKING) THIS
PROBLEM.  AND I KNOW I'M TRYING TO CATCH UP ON MANY, MANY
MOONS OF WORK DONE
BEFORE I LOOKED AT THE FIRST LINE OF MERGE TRACKING CODE. 
HOPEFULLY SOMEONE
CAN SET ME STRAIGHT RIGHT QUICK AND, AS A RESULT, EDUCATE
THE COMMUNITY AS A
WHOLE.

-- 
C. MICHAEL PILATO <CMPILATOCOLLAB.NET>
COLLABNET   <>   WWW.COLLAB.NET   <>  
DISTRIBUTED DEVELOPMENT ON DEMAND

On 11/6/07, C. Michael Pilato <cmpilatocollab.net> wrote:
> Mark Phippard wrote:
> > You have to take everything I say with a grain of
salt because since I
> > do not work down in the code I could use terms
different than Dan,
> > Paul etc do.  That being said, I view there are
two kinds of
> > mergeinfo:
> >
> > implicit - this is created at the time a path is
created.  It is the
> > history of revisions and paths that initially make
up the item.
> >
> > explicit - everything that is merged into the path
after it is created.
>
> Yes, I understand your definitions.  I don't understand
why those are the
> definitions chosen.
>
> My understanding of the whole point of merge tracking
is that we're trying
> to keep track of all the sources of changes made to a
given directory that
> *are external to* the regular ol' update-edit-commit
cycle.  Copies are
> *not* external to that cycle.  A copy doesn't feed data
from some other
> source into an existing object -- quite the opposite. 
So I don't understand
> why 'svn copy trunk branches/my-branch' should record
mergeinfo on
> branches/my-branch.  The information there is
completely redundant with the
> information already contained in branches/my-branch's
history.  It doesn't
> represent changes brought into my-branch from some
other source, because
> that source is just my-branch itself prior to some name
change (which I
> posit is irrelevant from the standpoint of history
tracking).

Again, I do not understand what/why or even if you are
arguing.  I
thought the whole point of the issue you are looking at is
to make
this change that you outlined.  So why are you being
argumentative
about this aspect of it?  We are in agreement that it
probably can and
should be changed to the way you propose.

>
> > Perhaps I need to see your definitions.
>
> I provided them in my original mail:
>
>    Every node's ancestry set consists to two things:
>
>       1.  its natural version history (changes made and
committed
>           directly to the object or its children), and
>       2.  merges of changes made to alternate lines of
history.
>
>    The first of these we call "implicit
mergeinfo"; the latter "explicit
>    mergeinfo".  Explicit mergeinfo can be stored
literally on a node via
>    the svn:mergeinfo property, or can be inherited from
its parent
>    directory.

I am not sure I understand the significance of #1.  I think
you do
though and I am OK with it.

> >> This logic concerns me, and relates to a
question I asked Paul yesterday
> >> about svn:mergeinfo on a path having
references to merge sources from the
> >> same path.  Say I have a single branch (trunk)
that I'm working on, and need
> >> to undo a committed change.  I merge -c-N the
change.  Now, do we expect
> >> that the mergeinfo for trunk contains:
> >>
> >>    /trunk:-N
> >>
> >> ?  I say "no".  Why do I rate a
special record of an undoing commit, when I
> >> don't have any special records of
"doing" commits?
> >
> > I say "no" too.  If a path is created by
copying trunk at r100 you get
> > this mergeinfo:
> >
> > /trunk:1-100
> >
> > If you do a reverse merge of revision 90, the
mergeinfo should be
> > changed to this:
> >
> > /trunk:1-89,91-100
>
> You changed the scenario.  I didn't say anything about
a copy.  I'm talking
> about simply using merge to undo a revision previously
made on a given line
> of history.  Should we record that fact or not?
>
> But let's look at your example, incorporating mine into
to.  We have a
> trunk, and we have a branch 'foo' created from
trunk100.  In r90 of the
> trunk, someone committed a nasty bug.  In r110, they
reverse-merged r90 and
> committed, effectively undoing the bug introduction.
>
> So, first things first.  When the reverse-merge of r90
was committed to
> trunk as r110, did it introduce mergeinfo *on trunk
itself* of:
>
>    /trunk:-90

I do not think we do, in fact I am fairly sure that we do
not.  We
even recently committed code to special case a reverse merge
of a
revision to yourself so that it does not require mergeinfo. 
That
being said, with your changes I suspect it could be modified
to be
something like what you are proposing.  I am not really sure
why
/trunk needs to know this bit of information about itself
though.

> The answer to this question is critical to my
understanding of what we're
> trying to do here; hand-waving around this is not an
option for me.

I do not think anyone is hand-waving.  It is kind of up to
you to
redefine this based on the changes you envision making.  I
*think* my
answers explain what we do today.

> Moving on, using my definition of implicit mergeinfo
(which is a misnomer,
> really, as it has nothing to do with merging), when I
created the branch
> 'foo' from trunk100, there was no need to record any
mergeinfo whatsoever
> yet.  I had not yet introduced changes to 'foo' from an
alternate line of
> history.  I had merely forked a single line of
history.
>
> Now I wish to merge the bugfix from the trunk.  There
are a few ways to do this.
>
> First, I could merge the undoing revision committed in
r110.
>
>    $ svn merge -c 110 http://.../trunk trunk
>
> To me, this now earns 'foo' some mergeinfo:
>
>    /trunk:110
>
> Why?  Because this is the first time in the history of
'foo' that the source
> of our changes was some alternate line of history (the
other tong of our
> fork from trunk).
>
> Alternatively, we could reverse-merge r90 onto 'foo'
using trunk as the
> source, fixing the bug on our branch the same way it
was fixed on the trunk.
>
>    $ svn merge -c -90 http://.../trunk branches/foo
>
> But here's where I question what happens.  Should 'foo'
get mergeinfo now?
>
>    /trunk:-90

The best I can say is maybe.  It could possibly get the
mergeinfo you
are proposing, or it could get something like this:

/trunk:1-89,91-100

It probably depends on what the "ripple effect" of
changing this now
would entail.  Thinking of things like non-inheritable
revisions,
elision etc.

> In my opinion, this is *exactly the same scenario* as
when we reverse-merged
> r90 on trunk itself, and therefore should have exactly
the same results.

That is an interesting argument.  I cannot say that I
disagree.  I
think in spirit we were trying to work this way today.  Your
ideas
seem to add a lot more intelligence to the process by
recognizing the
ancestry of a path and not just going by the name.

> Finally, we could reverse-merge r90 using 'foo' as the
source.
>
>    $ svn merge -c -90 http://.../branches/foo
branches/foo
>
> But my merge source normalization logic would
internally remap this as a
> reverse-merge of r90 using trunk as the source, so this
becomes the same as
> the previous method.

Great.

> I'm terribly sorry if I'm overthinking (or worse,
underthinking) this
> problem.  And I know I'm trying to catch up on many,
many moons of work done
> before I looked at the first line of merge tracking
code.  Hopefully someone
> can set me straight right quick and, as a result,
educate the community as a
> whole.

It seems like you have been on the mark with your analysis. 
Is there
some other shoe to drop if we agree that this is the way to
go?  I
guess I do not understand some of what you are asking,
because you
seem to be arguing about the current design and I thought
that was the
whole point of why you were looking at this in the first
place ... to
improve/change it.

Hopefully Dan will chime in.

-- 
Thanks

Mark Phippard
http://markphip.blogspo
t.com/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

MARK PHIPPARD WROTE:
> IT SEEMS LIKE YOU HAVE BEEN ON THE MARK WITH YOUR
ANALYSIS.  IS THERE
> SOME OTHER SHOE TO DROP IF WE AGREE THAT THIS IS THE
WAY TO GO?  I
> GUESS I DO NOT UNDERSTAND SOME OF WHAT YOU ARE ASKING,
BECAUSE YOU
> SEEM TO BE ARGUING ABOUT THE CURRENT DESIGN AND I
THOUGHT THAT WAS THE
> WHOLE POINT OF WHY YOU WERE LOOKING AT THIS IN THE
FIRST PLACE ... TO
> IMPROVE/CHANGE IT.

THIS WHOLE THREAD EXISTS BECAUSE I SEE SOME PROBLEMS WITH
THE CURRENT
DESIGN, AND I NEED TO FIGURE OUT WHICH OF THOSE PROBLEMS ARE
REALLY
PROBLEMS, AND WHICH OF THEM ONLY LOOK LIKE PROBLEMS BECAUSE
I HAVEN'T BEEN
THINKING ABOUT MERGE TRACKING FOR 9 MONTHS LIKE SOME FOLKS
HAVE.

-- 
C. MICHAEL PILATO <CMPILATOCOLLAB.NET>
COLLABNET   <>   WWW.COLLAB.NET   <>  
DISTRIBUTED DEVELOPMENT ON DEMAND

> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilatocollab.net] 
> Sent: Tuesday, November 06, 2007 10:14 AM
> To: Mark Phippard
> Cc: Daniel Rall; Subversion Developers
> Subject: Re: Reconstructing thoughts about implicit
mergeinfo

<snip>
 
> You changed the scenario.  I didn't say anything about
a 
> copy.  I'm talking about simply using merge to undo a 
> revision previously made on a given line of history. 
Should 
> we record that fact or not?
> 
> But let's look at your example, incorporating mine into
to.  
> We have a trunk, and we have a branch 'foo' created
from 
> trunk100.  In r90 of the trunk, someone committed a nasty

> bug.  In r110, they reverse-merged r90 and committed, 
> effectively undoing the bug introduction.

Hi Mike,

I'd like to mirror your example here, but use the definition
of implicit
mergeinfo that exists on trunk today.  Though I'm sure you
have already
done this it might be useful for others reading this (and
maybe
something enlightening will fall out of this).

> So, first things first.  When the reverse-merge of r90
was
> committed to trunk as r110, did it introduce mergeinfo
*on
> trunk itself* of:
>
>   /trunk:-90

While r27519 http://subversion.tigris.org/issues/show_bug.cgi?id=2973

purposely special cased reverse mergeing where source and
target are the
same, i.e. it allows this

  $ svn merge -c-90 http://.../trunk trunk

to work, it *doesn't* change trunk's mergeinfo because we
currently
don't support negated revision ranges -- FWIW a concept
which has other
applications: http://subversion.tigris.org/issues/show_bug.cgi?id=288
1.

> The answer to this question is critical to my
understanding 
> of what we're trying to do here; hand-waving around
this is 
> not an option for me.
> 
> Moving on, using my definition of implicit mergeinfo
(which 
> is a misnomer, really, as it has nothing to do with
merging), 
> when I created the branch 'foo' from trunk100,
there was no 
> need to record any mergeinfo whatsoever yet.

Ok, today (r27617) when we create 'foo' from trunk100 'foo'
gets
implicit mergeinfo from trunk of:

  '/trunk:1-100' (assuming for now that 'trunk' was created
in r1)

So 'foo' earns some mergeinfo as soon as it is copied.  And
once the
copy is done, 'foo' has mergeinfo, there is no real concept
of it having
special 'implicit' mergeinfo. 

> I had not yet 
> introduced changes to 'foo' from an alternate line of 
> history.  I had merely forked a single line of
history.
> 
> Now I wish to merge the bugfix from the trunk.  There
are a 
> few ways to do this.
> 
> First, I could merge the undoing revision committed in
r110.
> 
>    $ svn merge -c 110 http://.../trunk trunk
> 
> To me, this now earns 'foo' some mergeinfo:
> 
>    /trunk:110

Today foo gets r110 added to it's mergeinfo too, resulting
in:

'/trunk:1-100,110'

> Why?  Because this is the first time in the history of
'foo' 
> that the source of our changes was some alternate line
of 
> history (the other tong of our fork from trunk).
> 
> Alternatively, we could reverse-merge r90 onto 'foo'
using 
> trunk as the source, fixing the bug on our branch the
same 
> way it was fixed on the trunk.
> 
>    $ svn merge -c -90 http://.../trunk branches/foo
> 
> But here's where I question what happens.  Should 'foo'
get 
> mergeinfo now?
> 
>    /trunk:-90

On trunk today this sets foo's mergeinfo to:

'/trunk:1-89,91-100'

I hadn't previously appreciated that we can end up with the
same net
effect on foo's contents but have two different ways of
describing it in
foo's mergeinfo -- though I'm not sure if this is a
problem.

> In my opinion, this is *exactly the same scenario* as
when we 
> reverse-merged r90 on trunk itself, and therefore
should have 
> exactly the same results.

Well it does have the same results in everything *except*
the mergeinfo,
is this really a problem?  To make it identical we'd have to
implement
negeated revision ranges in svn:mergeinfo, and that gets
back to one of
your other questions, "Why do I rate a special record
of an undoing
commit, when I don't have any special records of 'doing'
commits?"

> Finally, we could reverse-merge r90 using 'foo' as the
source.
> 
>    $ svn merge -c -90 http://.../branches/foo
branches/foo
> 
> But my merge source normalization logic would
internally 
> remap this as a reverse-merge of r90 using trunk as the

> source, so this becomes the same as the previous
method.

Today this operates exactly the same too.
 
> I'm terribly sorry if I'm overthinking (or worse, 
> underthinking) this problem.

Probably neither, the implicit mergeinfo from copies has
been in place
from early on.  Speaking for myself I've been guilty of
thinking "that's
just the way it works" and not seeing potential
problems while wrestling
around in the mud of elision, non-inheritable ranges, etc.

Sorry if this just muddies the waters, trying to step back
and think
about this some more too...

Paul

> And I know I'm trying to catch 
> up on many, many moons of work done before I looked at
the 
> first line of merge tracking code.  Hopefully someone
can set 
> me straight right quick and, as a result, educate the 
> community as a whole.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org