On 10/19/07, Kamesh Jayachandran <email@example.com> wrote:
> Mark Phippard wrote:
> > On 10/19/07, Kamesh Jayachandran <firstname.lastname@example.org> 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.
> 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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Oct 19 13:27:10 2007