On 11/6/07, C. Michael Pilato <cmpilato@collab.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 trunk@100. 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 trunk@100, 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.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 16:31:57 2007