You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2006/01/25 20:37:49 UTC

Re: svn commit: r18231 - branches/1.3.x

djames@tigris.org wrote:
> Author: djames
> Date: Wed Jan 25 14:09:41 2006
> New Revision: 18231
> 
> Modified:
>    branches/1.3.x/STATUS
> 
> Log:
> * STATUS: Nominate and vote for r18230. Vote +1 (concept) on r18215, noting
>   that r18215 needs a merge branch to resolve conflicts.

Do we have a policy on how much of a conflict is required before using a merge 
branch?

This commit was trivial (2 lines in configure.in) and could be done by hand in 
the 1.3.x branch to resolve it.  In fact, the easy was would be to do the merge, 
revert configure.in and make the change by hand.

Maybe using a branch isn't a bad idea :)

Regards,
Blair

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r18231 - branches/1.3.x

Posted by Blair Zajac <bl...@orcaware.com>.
David James wrote:
>>>I looked at r18215, and I didn't find it was immediately obvious how
>>>to merge it to the 1.3.x branch. For this reason, I'd like to see a
>>>merge branch before I can approve the change.
>>
>>When I did the merge, I was surprised to see how and what was marked as a conflict.
>>
>>But look at the original commit and you'll see it's a trivial two lines and
>>could be applied by hand.
> 
> Thanks! Using your instructions, I've created a merge branch to do
> this. It's in the STATUS file.
> 
> Cheers,
> 
> David

Thanks David!

Regards,
Blair

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r18231 - branches/1.3.x

Posted by David James <dj...@collab.net>.
> > I looked at r18215, and I didn't find it was immediately obvious how
> > to merge it to the 1.3.x branch. For this reason, I'd like to see a
> > merge branch before I can approve the change.
> When I did the merge, I was surprised to see how and what was marked as a conflict.
>
> But look at the original commit and you'll see it's a trivial two lines and
> could be applied by hand.
Thanks! Using your instructions, I've created a merge branch to do
this. It's in the STATUS file.

Cheers,

David


--
David James -- http://www.cs.toronto.edu/~james

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org


Re: svn commit: r18231 - branches/1.3.x

Posted by Blair Zajac <bl...@orcaware.com>.
David James wrote:
> On 1/25/06, Blair Zajac <bl...@orcaware.com> wrote:
> 
>>djames@tigris.org wrote:
>>
>>>Author: djames
>>>Date: Wed Jan 25 14:09:41 2006
>>>New Revision: 18231
>>>
>>>Modified:
>>>   branches/1.3.x/STATUS
>>>
>>>Log:
>>>* STATUS: Nominate and vote for r18230. Vote +1 (concept) on r18215, noting
>>>  that r18215 needs a merge branch to resolve conflicts.
>>
>>Do we have a policy on how much of a conflict is required before using a merge
>>branch?
>>
>>This commit was trivial (2 lines in configure.in) and could be done by hand in
>>the 1.3.x branch to resolve it.  In fact, the easy was would be to do the merge,
>>revert configure.in and make the change by hand.
>>
>>Maybe using a branch isn't a bad idea :)
> 
> 
> I looked at r18215, and I didn't find it was immediately obvious how
> to merge it to the 1.3.x branch. For this reason, I'd like to see a
> merge branch before I can approve the change.

When I did the merge, I was surprised to see how and what was marked as a conflict.

But look at the original commit and you'll see it's a trivial two lines and 
could be applied by hand.

Regards,
Blair

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r18231 - branches/1.3.x

Posted by David James <dj...@collab.net>.
On 1/25/06, Blair Zajac <bl...@orcaware.com> wrote:
> djames@tigris.org wrote:
> > Author: djames
> > Date: Wed Jan 25 14:09:41 2006
> > New Revision: 18231
> >
> > Modified:
> >    branches/1.3.x/STATUS
> >
> > Log:
> > * STATUS: Nominate and vote for r18230. Vote +1 (concept) on r18215, noting
> >   that r18215 needs a merge branch to resolve conflicts.
>
> Do we have a policy on how much of a conflict is required before using a merge
> branch?
>
> This commit was trivial (2 lines in configure.in) and could be done by hand in
> the 1.3.x branch to resolve it.  In fact, the easy was would be to do the merge,
> revert configure.in and make the change by hand.
>
> Maybe using a branch isn't a bad idea :)

I looked at r18215, and I didn't find it was immediately obvious how
to merge it to the 1.3.x branch. For this reason, I'd like to see a
merge branch before I can approve the change.

In general, I'd say it's best to use merge branches for all
conflicting backports, because it's the safest thing to do. I don't
want to approve a change and then later find out that the change was
merged incorrectly.

Thanks,

David

--
David James -- http://www.cs.toronto.edu/~james

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org