Martin v. Löwis wrote:
>> I can see how "svn resolved ." gets it right (now that I understand how
>> the conflict is being produced and then fixed automatically by svnmerge,
>> but not actually marked as resolved).
>>
>> I still don't understand how "svn revert ." can avoid losing the
>> metadata c
> I can see how "svn resolved ." gets it right (now that I understand how
> the conflict is being produced and then fixed automatically by svnmerge,
> but not actually marked as resolved).
>
> I still don't understand how "svn revert ." can avoid losing the
> metadata changes unless svnmerge is to
Martin v. Löwis wrote:
> See above. You claim that doing things the way I recommend will lose
> metadata; I believe this claim is false.
I can see how "svn resolved ." gets it right (now that I understand how
the conflict is being produced and then fixed automatically by svnmerge,
but not actually
> (I believe that svnmerge actually does get that case right, but I
> haven't checked it extensively - since if it does get it right, I don't
> understand why it leaves the conflict in place instead of automatically
> marking it as resolved).
I think this is a plain bug. It invokes "svn merge", wh
>> Ah. In the 3.0 branch, always do "svn revert ." after svnmerge.
>> It's ok (Nick says it isn't exactly ok, but I don't understand why)
>
> Doing "svn revert ." before making the commit will lose the metadata
> changes that svnmerge uses for its bookkeeping (i.e. if this practice is
> used regul
Antoine Pitrou wrote:
> Nick Coghlan gmail.com> writes:
>> Doing "svn resolved ." assumes that you did everything else correctly,
>> and even then I don't see how svnmerge could both backport the py3k
>> changes to the metadata and make its own changes and still get the
>> metadata to a sane state
Nick Coghlan gmail.com> writes:
>
> Doing "svn resolved ." assumes that you did everything else correctly,
> and even then I don't see how svnmerge could both backport the py3k
> changes to the metadata and make its own changes and still get the
> metadata to a sane state.
The metadata are discr
Martin v. Löwis wrote:
>> There are potential problems with doing it that way [1]. The safer
>> option is to do:
>>
>> svn revert .
>> svnmerge merge -M -F
>
> I still don't see the potential problem. If you do svnmerge, svn commit,
> all is fine, right?
Sort of. svnmerge still gets confused by
Martin v. Löwis wrote:
>> svn up
>> svnmerge
>> ... conflicts
>> svn revert -R .
>> svn up
>> svnmerge
>> ... same conflicts
>
> Ah. In the 3.0 branch, always do "svn revert ." after svnmerge.
> It's ok (Nick says it isn't exactly ok, but I don't understand why)
Doing "svn revert ." before making
> svn up
> svnmerge
> ... conflicts
> svn revert -R .
> svn up
> svnmerge
> ... same conflicts
Ah. In the 3.0 branch, always do "svn revert ." after svnmerge.
It's ok (Nick says it isn't exactly ok, but I don't understand why)
Martin
___
Python-Dev mail
On Thu, Jan 29, 2009 at 19:03, "Martin v. Löwis" wrote:
> Brett Cannon wrote:
>> On Thu, Jan 29, 2009 at 18:27, "Martin v. Löwis" wrote:
There are potential problems with doing it that way [1]. The safer
option is to do:
svn revert .
svnmerge merge -M -F
>>> I still don'
Brett Cannon wrote:
> On Thu, Jan 29, 2009 at 18:27, "Martin v. Löwis" wrote:
>>> There are potential problems with doing it that way [1]. The safer
>>> option is to do:
>>>
>>> svn revert .
>>> svnmerge merge -M -F
>> I still don't see the potential problem. If you do svnmerge, svn commit,
>> al
On Thu, Jan 29, 2009 at 18:27, "Martin v. Löwis" wrote:
>> There are potential problems with doing it that way [1]. The safer
>> option is to do:
>>
>> svn revert .
>> svnmerge merge -M -F
>
> I still don't see the potential problem. If you do svnmerge, svn commit,
> all is fine, right? The probl
> There are potential problems with doing it that way [1]. The safer
> option is to do:
>
> svn revert .
> svnmerge merge -M -F
I still don't see the potential problem. If you do svnmerge, svn commit,
all is fine, right? The problem *only* arises if you do svnmerge,
svn up, svn commit - and clea
14 matches
Mail list logo