You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jack Repenning <jr...@collab.net> on 2007/10/18 13:15:36 UTC
reverse-merge broken?
Is this wrong? Or have I just somehow forgotten how reverse merges
should work?
% svn merge some://url/to/some/branch
(changes happen)
% svn ci -m"check the merge in"
(some changes get committed)
% svn up
At revision 17.
% svn merge -c-17
--- Reverse-merging r17 into '.':
(but nothing else!)
% svn stat
(nothing)
Shouldn't that merge command undo the changes that went into revision
17, leaving me with local mods (matching what I had back at r16,
before the merge and commit)?
I'm looking at a private build of r27129. (OS X, if you want to
care). The repository was created, and has only been touched by,
this same build (it's a tiny demo repo I set up for, well, a demo --
just contains the greek tree).
Happy to provide a detailed reproduction script, dump of the
repository at the outset, and all that, but thought I'd confirm that
my head's on straight first.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reverse-merge broken?
Posted by Mark Phippard <ma...@gmail.com>.
On 10/18/07, Jack Repenning <jr...@collab.net> wrote:
> Is this wrong? Or have I just somehow forgotten how reverse merges
> should work?
>
> % svn merge some://url/to/some/branch
> (changes happen)
> % svn ci -m"check the merge in"
> (some changes get committed)
> % svn up
> At revision 17.
> % svn merge -c-17
> --- Reverse-merging r17 into '.':
> (but nothing else!)
> % svn stat
> (nothing)
>
> Shouldn't that merge command undo the changes that went into revision
> 17, leaving me with local mods (matching what I had back at r16,
> before the merge and commit)?
>
> I'm looking at a private build of r27129. (OS X, if you want to
> care). The repository was created, and has only been touched by,
> this same build (it's a tiny demo repo I set up for, well, a demo --
> just contains the greek tree).
>
> Happy to provide a detailed reproduction script, dump of the
> repository at the outset, and all that, but thought I'd confirm that
> my head's on straight first.
It appears to be broken in certain scenarios. See:
http://subversion.tigris.org/issues/show_bug.cgi?id=2973
--
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
Re: reverse-merge broken?
Posted by Kamesh Jayachandran <ka...@collab.net>.
> Since a reverse merge is always going to be an explicit user
> operation, maybe we ought to just not try to avoid repeat reverse
> merges? The user has already signified they want to reverse the
> merge, so why not just try to do it? What is the scenario where this
> is going to lead to incorrect behavior?
>
>
merge_tests-67 exhibits one behaviour which needs 'avoid repeat reverse
merge'.
The usecase is
1)Merge -rX:Y(X<Y) to 'target' from 'src'
2)Revert Z(X<Z<Y) on some subtree of target
3)Revert rY:X to 'target' would cause a conflict.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reverse-merge broken?
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
On Thu, 18 Oct 2007, Mark Phippard wrote:
> On 10/18/07, Daniel L. Rall <dl...@finemaltcoding.com> wrote:
> > On Thu, 18 Oct 2007, Mark Phippard wrote:
...
> > > Since a reverse merge is always going to be an explicit user
> > > operation, maybe we ought to just not try to avoid repeat reverse
> > > merges? The user has already signified they want to reverse the
> > > merge, so why not just try to do it? What is the scenario where this
> > > is going to lead to incorrect behavior?
> >
> > We absolutely have to perform the reverse merge, regardless of mergeinfo
> > on the merge target.
>
> My initial instinct was the same, but thinking some more. Suppose you
> merge something. Then reverse merge part of it. Then later decide to
> reverse merge all of it. Would we want it to be able to use the
> mergeinfo here to understand the situation and not repeat parts of the
> reverse merge?
>
> Or would we just think it does not matter or is not worth it?
See other response -- this seems to be necessary for backwards compat.
Re: reverse-merge broken?
Posted by Jack Repenning <jr...@collab.net>.
On Oct 19, 2007, at 3:05 AM, Mark Phippard wrote:
> On 10/18/07, Daniel L. Rall <dl...@finemaltcoding.com> wrote:
>> We absolutely have to perform the reverse merge, regardless of
>> mergeinfo
>> on the merge target.
>
> My initial instinct was the same, but thinking some more. Suppose you
> merge something. Then reverse merge part of it. Then later decide to
> reverse merge all of it. Would we want it to be able to use the
> mergeinfo here to understand the situation and not repeat parts of the
> reverse merge?
>
> Or would we just think it does not matter or is not worth it?
I think the "absolutely have to" thing is the simple case (indeed,
the one in my actual example):
1. merge branch to trunk
2. "merge -c-N" (also known as "woops")
More complicated stories are easy to weave, and there may be useful
things we can do by being clever with them, but the base story
doesn't go away, and "simple things easy, complex things possible"
says that the base case, and probably several not-much-more-complex
cases as well, "absolutely have to be doable."
I smell the possibility of complex stories we can detect but not
actually act upon, somewhere around here, and hope we'll consider
warnings to fill gaps, as well as those "do the right thing" cases we
can achieve.
In your example (partial reversal followed by full reversal), it
would certainly be best to "finish the reverse merge" rather than
"over-do the reverse merge." Not so good as that, but still better
than nothing, would be "over-do the reverse merge, but warn that
"file foo.rby may have been double-un-merged" (wow, Orwell lives!).
But even merely "over-doing the reverse merge" would be better than
"disabling the ability to do the simple un-merge." I could live with
any of those positions except the last (which, of course, is where we
are just now).
Some of those "not-much-more-complex cases that absolutely have to be
doable" might be:
Remote unmerge
1. merge branch to trunk
2. make unrelated changes in trunk
3. unmerge #1
Unmerge conflicts
1. merge branch to trunk
2. make (trunk) changes to lines delivered into trunk by #1
3. unmerge #1 produces a merge conflict over the lines mentioned in #2
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reverse-merge broken?
Posted by Mark Phippard <ma...@gmail.com>.
On 10/18/07, Daniel L. Rall <dl...@finemaltcoding.com> wrote:
> On Thu, 18 Oct 2007, Mark Phippard wrote:
>
> > On 10/18/07, Kamesh Jayachandran <ka...@collab.net> wrote:
> >
> > > Do you have any mergeinfo on a target from the corresponding merge
> > > source? Then only the 'avoid repeat reverse merge code kicks in' and
> > > hence no reverse merge.
> > >
> > > Probably we may need '--merge-insensitive' or '-G' to support repeat
> > > reverse merge.
> >
> > Since a reverse merge is always going to be an explicit user
> > operation, maybe we ought to just not try to avoid repeat reverse
> > merges? The user has already signified they want to reverse the
> > merge, so why not just try to do it? What is the scenario where this
> > is going to lead to incorrect behavior?
>
> We absolutely have to perform the reverse merge, regardless of mergeinfo
> on the merge target.
My initial instinct was the same, but thinking some more. Suppose you
merge something. Then reverse merge part of it. Then later decide to
reverse merge all of it. Would we want it to be able to use the
mergeinfo here to understand the situation and not repeat parts of the
reverse merge?
Or would we just think it does not matter or is not worth it?
--
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
Re: reverse-merge broken?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Mark Phippard wrote:
> On 10/19/07, Kamesh Jayachandran <ka...@collab.net> wrote:
>
>> Mark Phippard wrote:
>>
>>> On 10/19/07, Kamesh Jayachandran <ka...@collab.net> wrote:
>>>
>>>
>>>>> We absolutely have to perform the reverse merge, regardless of mergeinfo
>>>>> on the merge target.
>>>>>
>>>>>
>>>>>
>>>> As I voiced my opinion on other email, what about *allow repeat reverse
>>>> merge from merge source same as that of the target only*.?
>>>>
>>>>
>>> That actually seems like a good idea to me. You are saying if I am in
>>> trunk, and I do a reverse merge of any change that occurred in trunk
>>> it would allow it and do it like it does in 1.4. But, if I did a
>>> reverse merge in trunk by specifying changes from some branch it would
>>> use the mergeinfo to determine what to do?
>>>
>>>
>>>
>> Yes.
>>
>>
>>> If so, then I think that makes a lot of sense and is justifiable. I'd
>>> probably even argue that it ought to be working like that already has
>>> /trunk would not have mergeinfo about itself anyway .. would it? If I
>>> make a change and commit, I do not get mergeinfo added. So without
>>> this logic, I could not reverse merge that commit.
>>>
>>>
>>>
>> It won't, but it can come via a merge from its copy back to itself.
>> i.e, svn cp trunk branches/b1; do some change on branches/b1; merge b1
>> to trunk;
>> Above chain of activity would bring along with change on branch b1 would
>> bring its 'copy from mergeinfo' that is trunk itself.
>>
>
> Right, but I was thinking of a simpler scenario. User only ever works
> on trunk, does not even do branching. They want to do undo a commit.
> There is no mergeinfo at all. They ought to be able to do this and it
> sounds like with the current code they can't.
With current code this particular case works. It starts failing only
when it has 'confusing self merge history' via feature branch merge back
like our 'http://svn.collab.net/repos/svn/trunk'.
Proposed solution will handle it much cleaner.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reverse-merge broken?
Posted by Mark Phippard <ma...@gmail.com>.
On 10/19/07, Kamesh Jayachandran <ka...@collab.net> wrote:
>
>
> Mark Phippard wrote:
> > On 10/19/07, Kamesh Jayachandran <ka...@collab.net> wrote:
> >
> >>
> >>> We absolutely have to perform the reverse merge, regardless of mergeinfo
> >>> on the merge target.
> >>>
> >>>
> >> As I voiced my opinion on other email, what about *allow repeat reverse
> >> merge from merge source same as that of the target only*.?
> >>
> >
> > That actually seems like a good idea to me. You are saying if I am in
> > trunk, and I do a reverse merge of any change that occurred in trunk
> > it would allow it and do it like it does in 1.4. But, if I did a
> > reverse merge in trunk by specifying changes from some branch it would
> > use the mergeinfo to determine what to do?
> >
> >
> Yes.
>
> > If so, then I think that makes a lot of sense and is justifiable. I'd
> > probably even argue that it ought to be working like that already has
> > /trunk would not have mergeinfo about itself anyway .. would it? If I
> > make a change and commit, I do not get mergeinfo added. So without
> > this logic, I could not reverse merge that commit.
> >
> >
> It won't, but it can come via a merge from its copy back to itself.
> i.e, svn cp trunk branches/b1; do some change on branches/b1; merge b1
> to trunk;
> Above chain of activity would bring along with change on branch b1 would
> bring its 'copy from mergeinfo' that is trunk itself.
Right, but I was thinking of a simpler scenario. User only ever works
on trunk, does not even do branching. They want to do undo a commit.
There is no mergeinfo at all. They ought to be able to do this and it
sounds like with the current code they can't. So this needs to be
fixed and "special-cased" regardless. Now, I also think that doing
this fix also provides a reasonable solution to the problem in
general, but we'll have to see what Dan and others have to say.
--
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
Re: reverse-merge broken?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Mark Phippard wrote:
> On 10/19/07, Kamesh Jayachandran <ka...@collab.net> wrote:
>
>>
>>> We absolutely have to perform the reverse merge, regardless of mergeinfo
>>> on the merge target.
>>>
>>>
>> As I voiced my opinion on other email, what about *allow repeat reverse
>> merge from merge source same as that of the target only*.?
>>
>
> That actually seems like a good idea to me. You are saying if I am in
> trunk, and I do a reverse merge of any change that occurred in trunk
> it would allow it and do it like it does in 1.4. But, if I did a
> reverse merge in trunk by specifying changes from some branch it would
> use the mergeinfo to determine what to do?
>
>
Yes.
> If so, then I think that makes a lot of sense and is justifiable. I'd
> probably even argue that it ought to be working like that already has
> /trunk would not have mergeinfo about itself anyway .. would it? If I
> make a change and commit, I do not get mergeinfo added. So without
> this logic, I could not reverse merge that commit.
>
>
It won't, but it can come via a merge from its copy back to itself.
i.e, svn cp trunk branches/b1; do some change on branches/b1; merge b1
to trunk;
Above chain of activity would bring along with change on branch b1 would
bring its 'copy from mergeinfo' that is trunk itself.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reverse-merge broken?
Posted by Mark Phippard <ma...@gmail.com>.
On 10/19/07, Kamesh Jayachandran <ka...@collab.net> wrote:
>
>
> > We absolutely have to perform the reverse merge, regardless of mergeinfo
> > on the merge target.
> >
>
> As I voiced my opinion on other email, what about *allow repeat reverse
> merge from merge source same as that of the target only*.?
That actually seems like a good idea to me. You are saying if I am in
trunk, and I do a reverse merge of any change that occurred in trunk
it would allow it and do it like it does in 1.4. But, if I did a
reverse merge in trunk by specifying changes from some branch it would
use the mergeinfo to determine what to do?
If so, then I think that makes a lot of sense and is justifiable. I'd
probably even argue that it ought to be working like that already has
/trunk would not have mergeinfo about itself anyway .. would it? If I
make a change and commit, I do not get mergeinfo added. So without
this logic, I could not reverse merge that commit.
--
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
Re: reverse-merge broken?
Posted by Kamesh Jayachandran <ka...@collab.net>.
> We absolutely have to perform the reverse merge, regardless of mergeinfo
> on the merge target.
>
As I voiced my opinion on other email, what about *allow repeat reverse
merge from merge source same as that of the target only*.?
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reverse-merge broken?
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
On Thu, 18 Oct 2007, Mark Phippard wrote:
> On 10/18/07, Kamesh Jayachandran <ka...@collab.net> wrote:
>
> > Do you have any mergeinfo on a target from the corresponding merge
> > source? Then only the 'avoid repeat reverse merge code kicks in' and
> > hence no reverse merge.
> >
> > Probably we may need '--merge-insensitive' or '-G' to support repeat
> > reverse merge.
>
> Since a reverse merge is always going to be an explicit user
> operation, maybe we ought to just not try to avoid repeat reverse
> merges? The user has already signified they want to reverse the
> merge, so why not just try to do it? What is the scenario where this
> is going to lead to incorrect behavior?
We absolutely have to perform the reverse merge, regardless of mergeinfo
on the merge target.
--
Daniel Rall
Re: reverse-merge broken?
Posted by Mark Phippard <ma...@gmail.com>.
On 10/18/07, Kamesh Jayachandran <ka...@collab.net> wrote:
> Do you have any mergeinfo on a target from the corresponding merge
> source? Then only the 'avoid repeat reverse merge code kicks in' and
> hence no reverse merge.
>
> Probably we may need '--merge-insensitive' or '-G' to support repeat
> reverse merge.
Since a reverse merge is always going to be an explicit user
operation, maybe we ought to just not try to avoid repeat reverse
merges? The user has already signified they want to reverse the
merge, so why not just try to do it? What is the scenario where this
is going to lead to incorrect behavior?
--
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
Re: reverse-merge broken?
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
On Fri, 19 Oct 2007, Jack Repenning wrote:
> On Oct 18, 2007, at 4:35 PM, Kamesh Jayachandran wrote:
>
> >Jack,
> >
> >Do you have any mergeinfo on a target from the corresponding merge
> >source?
>
>
> Yes:
> > svn plist -vR .
> Properties on '.':
> svn:mergeinfo : /branches/B1:4-16
> /trunk:3-7
> Properties on 'greek':
> svn:mergeinfo :
> Properties on 'greek/iota':
> svn:mergeinfo : /branches/B1/greek/iota:4-16
> /trunk/greek/iota:6-7
>
>
> I merged from branch B1 to (a working copy on) trunk, committed,
> updated, then attempted to reverse that very merge.
>
> >Then only the 'avoid repeat reverse merge code kicks in' and hence
> >no reverse merge.
> >
> >Probably we may need '--merge-insensitive' or '-G' to support
> >repeat reverse merge.
>
> I do not think we need any flags to mean "do the right thing" in this
> case. There is no conceivable other meaning to
>
> svn merge -c-17
>
> than "undo rev 17."
r17 isn't listed in the mergeinfo shown above.
Is it the "merged in" revision for some other transitive merge? If not,
you'd want r16 (e.g. 'svn merge -r16:15', rather than 'svn merge -r17:16').
> On Oct 18, 2007, at 4:54 PM, Mark Phippard wrote:
> >Since a reverse merge is always going to be an explicit user
> >operation, maybe we ought to just not try to avoid repeat reverse
> >merges? The user has already signified they want to reverse the
> >merge, so why not just try to do it? What is the scenario where this
> >is going to lead to incorrect behavior?
>
> Yes, that would be more reasonable than the present behavior.
>
> Better than both might be:
> 1. look at the svn:mergeinfo for the revision in the -c-XX flag
> 2. find which revisions were added to the branch history by that
> revision
> 3. look in the svn:mergeinfo for the current version
> 4. if the revisions added in #2 are still present, remove them;
> otherwise print/return a warning that the named change set is not in
> this revision, so it can't be removed
Unfortunately, the revision might still be in the target, but simply not
listed in the mergeinfo (e.g. because the merge was performed with a
pre-1.5 client before the userbase migrated to 1.5, and there is no record
of the merge occurring).
We still have to unmerge the revision. I'd be fine with this happening
with or without notification. I don't think a flag is necessary, but if
we do want a flag (-0 for 1.5), I'd suggest re-using --force.
--
Daniel Rall
Re: reverse-merge broken?
Posted by Jack Repenning <jr...@collab.net>.
On Oct 22, 2007, at 11:35 PM, Karl Fogel wrote:
> I'd not want to introduce another subcommand at this point in the game
> (*maybe* for 1.6, but we need time to really think/talk about it).
>
> However, is there any use to having a "-G" flag, meaning "do NOT
> affect mergeinfo", for merge and other commands?
I acknowledge the point about the disruption of a new subcommand; I
only mentioned it as a way to highlight this idea that there really
are two different operations here, we've flipped the one command from
one meaning to the other but we still explicitly cover only one.
Whether the option to do the other thing is "--ignore-ancestry" or
merely "-G" (that is, the number of characters to type) is rather
secondary. This is not about keyboard-labor, but about
comprehensibility and surprises.
As a practical matter, the case I ran into that got me started still
worries me. I noticed it because I was only merging one revision, so
it was obvious that nothing had happened -- and indeed, this special
case has been special-cased over. But I'm not convinced it's the
only "special case," and a more complicated one might not be so
obvious. It would be much more accessible if merge only did merge
(which might even make my "reverse merge failure" legitimate), and
some other command did "never mind the history, just do what I tell
you."
But I'm just spouting off. Maybe it's a wart, but particularly at
this point, we can live with it.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reverse-merge broken?
Posted by Karl Fogel <kf...@red-bean.com>.
Jack Repenning <jr...@collab.net> writes:
> Thanks for the clarification, Kamesh.
>
> At one time or another, I've heard people suggest that, as part of this
> merge-tracking work, we ought to have two subcommands:
>
> - patch: the old "merge", without merge info
> - merge: the new one, with merge info
>
> I guess that idea died. Too bad: this is a good illustration of the
> problem it was trying to solve. If you're thinking of "merge" as
> being "the thing with all this merge info history," then this case
> you call "self reversal" really isn't a merge at all; the "patch"
> command would be fine.
I'd not want to introduce another subcommand at this point in the game
(*maybe* for 1.6, but we need time to really think/talk about it).
However, is there any use to having a "-G" flag, meaning "do NOT
affect mergeinfo", for merge and other commands?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reverse-merge broken?
Posted by Jack Repenning <jr...@collab.net>.
Thanks for the clarification, Kamesh.
At one time or another, I've heard people suggest that, as part of
this merge-tracking work, we ought to have two subcommands:
- patch: the old "merge", without merge info
- merge: the new one, with merge info
I guess that idea died. Too bad: this is a good illustration of the
problem it was trying to solve. If you're thinking of "merge" as
being "the thing with all this merge info history," then this case
you call "self reversal" really isn't a merge at all; the "patch"
command would be fine.
On Oct 21, 2007, at 12:11 AM, Kamesh Jayachandran wrote:
> Jack,
>
> >There is only one attempted reverse-merge in my example, and indeed
> >that one doesn't do anything so far as I can see, so in some sense
> >there are zero. I don't understand, then, why you end up asking
> >questions about *repeat* reverse merges.
>
> As I mentioned in one of my email,
> * We don't record reverse merges *explicitly*, i.e no recording of
> mergeinfo /src:-17
>
> Please mean 'Avoid repeat reverse merge' === 'Allow reverse merges
> only if there exists a corresponding forward merge' to be more
> clear in our earlier discussions
>
> I agree it is annoying, We fixed this, by handing 'self
> reversals'(as your example) as a special case.
>
> P.S self reversals = reverse merge from same source as that of the
> target. After all rX committed on path /target implicitly
> equivalent 'merge of rX changeset from /target to /target'
>
> >Perhaps your thought is, more or less, "we have to do something or
> >other about repeat reverse merges, so what policy is acceptable on
> >that?"
>
> I don't think it is the policy change rather a way it should have
> been originally done as a part of 'avoid repeat reverse merge'.
>
> With regards
> Kamesh Jayachandran
>
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
RE: reverse-merge broken?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Jack,
>There is only one attempted reverse-merge in my example, and indeed
>that one doesn't do anything so far as I can see, so in some sense
>there are zero. I don't understand, then, why you end up asking
>questions about *repeat* reverse merges.
As I mentioned in one of my email,
* We don't record reverse merges *explicitly*, i.e no recording of mergeinfo /src:-17
Please mean 'Avoid repeat reverse merge' === 'Allow reverse merges only if there exists a corresponding forward merge' to be more clear in our earlier discussions
I agree it is annoying, We fixed this, by handing 'self reversals'(as your example) as a special case.
P.S self reversals = reverse merge from same source as that of the target. After all rX committed on path /target implicitly equivalent 'merge of rX changeset from /target to /target'
>Perhaps your thought is, more or less, "we have to do something or
>other about repeat reverse merges, so what policy is acceptable on
>that?"
I don't think it is the policy change rather a way it should have been originally done as a part of 'avoid repeat reverse merge'.
With regards
Kamesh Jayachandran
Re: reverse-merge broken?
Posted by Jack Repenning <jr...@collab.net>.
Kamesh,
There is only one attempted reverse-merge in my example, and indeed
that one doesn't do anything so far as I can see, so in some sense
there are zero. I don't understand, then, why you end up asking
questions about *repeat* reverse merges.
Perhaps your thought is, more or less, "we have to do something or
other about repeat reverse merges, so what policy is acceptable on
that?"
I would respond that no policy toward repeat reverse merges is
acceptable, if it means that simple reverse merges are broken.
Indeed I can't see what meaning there is to a policy on _repeat_
reverse merges, if the initial reverse merge can't happen!
On Oct 19, 2007, at 9:39 AM, Kamesh Jayachandran wrote:
>
>>> Jack,
>>>
>>> Do you have any mergeinfo on a target from the corresponding
>>> merge source?
>>
>>
>> Yes:
>> > svn plist -vR .
>> Properties on '.':
>> svn:mergeinfo : /branches/B1:4-16
>> /trunk:3-7
>
> This is the trigger of the failure.
>
>>> Since a reverse merge is always going to be an explicit user
>>> operation, maybe we ought to just not try to avoid repeat reverse
>>> merges? The user has already signified they want to reverse the
>>> merge, so why not just try to do it? What is the scenario where
>>> this
>>> is going to lead to incorrect behavior?
>>
>> Yes, that would be more reasonable than the present behavior.
>>
>> Better than both might be:
>> 1. look at the svn:mergeinfo for the revision in the -c-XX flag
>> 2. find which revisions were added to the branch history by that
>> revision
>> 3. look in the svn:mergeinfo for the current version
>> 4. if the revisions added in #2 are still present, remove them;
>> otherwise print/return a warning that the named change set is not
>> in this revision, so it can't be removed
>
> This is very confusing to me.
>
> In your dataset Step 1 gives
> svn:mergeinfo : /branches/B1:4-16
> /trunk:3-7
>
> Step 2 may give (You did not mention the rev range of the merge
> +commit)
> /branches/B1:4-16 (I am not sure how it got the merge from /trunk
> probably it could be regular prop merge from branches/B1 which may
> be a copy of trunk.)
>
> It looks like this algorithm might work for us, but may not be
> feasible to implement in a efficient way.
>
> I have one thought.
> What about *allow repeat reverse merge only for merge from the
> source corresponding to target.*?
>
> With regards
> Kamesh Jayachandran
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reverse-merge broken?
Posted by Kamesh Jayachandran <ka...@collab.net>.
>> Jack,
>>
>> Do you have any mergeinfo on a target from the corresponding merge
>> source?
>
>
> Yes:
> > svn plist -vR .
> Properties on '.':
> svn:mergeinfo : /branches/B1:4-16
> /trunk:3-7
This is the trigger of the failure.
>> Since a reverse merge is always going to be an explicit user
>> operation, maybe we ought to just not try to avoid repeat reverse
>> merges? The user has already signified they want to reverse the
>> merge, so why not just try to do it? What is the scenario where this
>> is going to lead to incorrect behavior?
>
> Yes, that would be more reasonable than the present behavior.
>
> Better than both might be:
> 1. look at the svn:mergeinfo for the revision in the -c-XX flag
> 2. find which revisions were added to the branch history by that revision
> 3. look in the svn:mergeinfo for the current version
> 4. if the revisions added in #2 are still present, remove them;
> otherwise print/return a warning that the named change set is not in
> this revision, so it can't be removed
This is very confusing to me.
In your dataset Step 1 gives
svn:mergeinfo : /branches/B1:4-16
/trunk:3-7
Step 2 may give (You did not mention the rev range of the merge+commit)
/branches/B1:4-16 (I am not sure how it got the merge from /trunk
probably it could be regular prop merge from branches/B1 which may be a
copy of trunk.)
It looks like this algorithm might work for us, but may not be feasible
to implement in a efficient way.
I have one thought.
What about *allow repeat reverse merge only for merge from the source
corresponding to target.*?
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reverse-merge broken?
Posted by Jack Repenning <jr...@collab.net>.
On Oct 18, 2007, at 4:35 PM, Kamesh Jayachandran wrote:
> Jack,
>
> Do you have any mergeinfo on a target from the corresponding merge
> source?
Yes:
> svn plist -vR .
Properties on '.':
svn:mergeinfo : /branches/B1:4-16
/trunk:3-7
Properties on 'greek':
svn:mergeinfo :
Properties on 'greek/iota':
svn:mergeinfo : /branches/B1/greek/iota:4-16
/trunk/greek/iota:6-7
I merged from branch B1 to (a working copy on) trunk, committed,
updated, then attempted to reverse that very merge.
> Then only the 'avoid repeat reverse merge code kicks in' and hence
> no reverse merge.
>
> Probably we may need '--merge-insensitive' or '-G' to support
> repeat reverse merge.
I do not think we need any flags to mean "do the right thing" in this
case. There is no conceivable other meaning to
svn merge -c-17
than "undo rev 17."
On Oct 18, 2007, at 4:54 PM, Mark Phippard wrote:
> Since a reverse merge is always going to be an explicit user
> operation, maybe we ought to just not try to avoid repeat reverse
> merges? The user has already signified they want to reverse the
> merge, so why not just try to do it? What is the scenario where this
> is going to lead to incorrect behavior?
Yes, that would be more reasonable than the present behavior.
Better than both might be:
1. look at the svn:mergeinfo for the revision in the -c-XX flag
2. find which revisions were added to the branch history by that
revision
3. look in the svn:mergeinfo for the current version
4. if the revisions added in #2 are still present, remove them;
otherwise print/return a warning that the named change set is not in
this revision, so it can't be removed
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reverse-merge broken?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Jack,
Do you have any mergeinfo on a target from the corresponding merge
source? Then only the 'avoid repeat reverse merge code kicks in' and
hence no reverse merge.
Probably we may need '--merge-insensitive' or '-G' to support repeat
reverse merge.
With regards
Kamesh Jayachandran
Kamesh Jayachandran wrote:
> Jack,
> Yes it is broken since the early days of merge tracking which I
> uncovered yesterday.
>
> Issue 2973 takes care of that.
>
> The cause of the failure is,
>
> We try to do reverse merge only if there was a forward merge in the
> past.(As an attempt to avoid repeat reverse merging I hope!!).
>
> This makes me to think 'If we don't track reverse merge why we should
> avoid repeat reverse merge'.
>
> Attaching the patch, merge tests 67 alone fails with this.
>
> Thanks.
> With regards
> Kamesh Jayachandran
>
> Jack Repenning wrote:
>> Is this wrong? Or have I just somehow forgotten how reverse merges
>> should work?
>>
>> % svn merge some://url/to/some/branch
>> (changes happen)
>> % svn ci -m"check the merge in"
>> (some changes get committed)
>> % svn up
>> At revision 17.
>> % svn merge -c-17
>> --- Reverse-merging r17 into '.':
>> (but nothing else!)
>> % svn stat
>> (nothing)
>>
>> Shouldn't that merge command undo the changes that went into revision
>> 17, leaving me with local mods (matching what I had back at r16,
>> before the merge and commit)?
>>
>> I'm looking at a private build of r27129. (OS X, if you want to
>> care). The repository was created, and has only been touched by,
>> this same build (it's a tiny demo repo I set up for, well, a demo --
>> just contains the greek tree).
>>
>> Happy to provide a detailed reproduction script, dump of the
>> repository at the outset, and all that, but thought I'd confirm that
>> my head's on straight first.
>>
>> -==-
>> Jack Repenning
>> Chief Technology Officer
>> CollabNet, Inc.
>> 8000 Marina Boulevard, Suite 600
>> Brisbane, California 94005
>> office: +1 650.228.2562
>> mobile: +1 408.835.8090
>> raindance: +1 877.326.2337, x844.7461
>> aim: jackrepenning
>> skype: jrepenning
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: reverse-merge broken?
Posted by Kamesh Jayachandran <ka...@collab.net>.
Jack,
Yes it is broken since the early days of merge tracking which I
uncovered yesterday.
Issue 2973 takes care of that.
The cause of the failure is,
We try to do reverse merge only if there was a forward merge in the
past.(As an attempt to avoid repeat reverse merging I hope!!).
This makes me to think 'If we don't track reverse merge why we should
avoid repeat reverse merge'.
Attaching the patch, merge tests 67 alone fails with this.
Thanks.
With regards
Kamesh Jayachandran
Jack Repenning wrote:
> Is this wrong? Or have I just somehow forgotten how reverse merges
> should work?
>
> % svn merge some://url/to/some/branch
> (changes happen)
> % svn ci -m"check the merge in"
> (some changes get committed)
> % svn up
> At revision 17.
> % svn merge -c-17
> --- Reverse-merging r17 into '.':
> (but nothing else!)
> % svn stat
> (nothing)
>
> Shouldn't that merge command undo the changes that went into revision
> 17, leaving me with local mods (matching what I had back at r16,
> before the merge and commit)?
>
> I'm looking at a private build of r27129. (OS X, if you want to
> care). The repository was created, and has only been touched by, this
> same build (it's a tiny demo repo I set up for, well, a demo -- just
> contains the greek tree).
>
> Happy to provide a detailed reproduction script, dump of the
> repository at the outset, and all that, but thought I'd confirm that
> my head's on straight first.
>
> -==-
> Jack Repenning
> Chief Technology Officer
> CollabNet, Inc.
> 8000 Marina Boulevard, Suite 600
> Brisbane, California 94005
> office: +1 650.228.2562
> mobile: +1 408.835.8090
> raindance: +1 877.326.2337, x844.7461
> aim: jackrepenning
> skype: jrepenning
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>