On 11/6/07, C. Michael Pilato <cmpilato@collab.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.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 6 15:26:50 2007