RE: svn commit: r1339892 -

From: Bert Huijben <bert_at_vmoo.com>
Date: Thu, 17 May 2012 22:34:06 -0700

/subversion/trunk/subversion/libsvn_fs/editor.c
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=f46d04428c9c9dfedd04c046d8da

--f46d04428c9c9dfedd04c046d8da
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Editor v1 only requires the revision for base node replacements and I
don't see why we need to change that for v2.

If we copied a subtree from a revision we know that that revision
didn't change. How could it be out of date?

Bert Huijben (Cell phone)
From: Greg Stein
Sent: 18-5-2012 5:07
To: Hyrum K Wright
Cc: dev_at_subversion.apache.org
Subject: Re: svn commit: r1339892
- /subversion/trunk/subversion/libsvn_fs/editor.c
On May 17, 2012 10:38 PM, "Hyrum K Wright" <hyrum.wright_at_wandisco.com>
wrote:
>
> Thanks for taking a look. It feels like all of these are issues with
> the complex copies and inheriting the correct replacement revision.
> The problem then lies back in the commit driver, but I don't think it
> will be too hard to track down.

Yeah. I seem to recall the specific code where a revision is tested against
its patent. Where those happen, simply use the parent rev for REPLACES_REV.

I think that might be in the harvester, where we set the COPY flag. Not
sure how that will translate over to the driver, or if it is even
applicable. I guess any copy-dest-within-dest needs the parent rev.

> The blame test failure is an unrelated EOL repairing issue.

Yeah, so I skipped looking into that one.

Cheers,
-g

--f46d04428c9c9dfedd04c046d8da
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html><head><meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Cont=
ent-Type"></head><body><div><div style=3D"font-family: Calibri,sans-serif; =
font-size: 11pt;">Editor v1 only requires the revision for base node replac=
ements and I don't see why we need to change that for v2. If we copi=
ed a subtree from a revision we know that that revision didn't change. How =
could it be out of date? Bert Huijben (Cell phone) </div></div><h=
r>From: Greg Stein Sent: 18-5-2012 5:07 <sp=
an style=3D"font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: b=
old;">To: Hyrum K Wright Cc: dev_at_subversion.apache.org<=
br>Subject: Re: svn commit: r1339892 - /subversion/trunk/subversion/l=
ibsvn_fs/editor.c </body></html> 
On May 17, 2012 10:38 PM, "Hyrum K Wright" <<a href=3D"mailto:=
hyrum.wright_at_wandisco.com">hyrum.wright_at_wandisco.com</a>> wrote: 
> 
> Thanks for taking a look. =C2=A0It feels like all of these are issues =
with 
> the complex copies and inheriting the correct replacement revision.<br=
>
> The problem then lies back in the commit driver, but I don't think=
it 
> will be too hard to track down.
Yeah. I seem to recall the specific code where a revision is tested agai=
nst its patent. Where those happen, simply use the parent rev for REPLACES_=
REV.
I think that might be in the harvester, where we set the COPY flag. Not =
sure how that will translate over to the driver, or if it is even applicabl=
e. I guess any copy-dest-within-dest needs the parent rev.
> The blame test failure is an unrelated EOL repairing issue.
Yeah, so I skipped looking into that one.
Cheers, 
-g

--f46d04428c9c9dfedd04c046d8da--
Received on 2012-05-18 07:34:49 CEST

This message: [ Message body ]
Next message: Greg Stein: "Re: svn commit: r1339892 -"
Previous message: Greg Stein: "Re: svn commit: r1339892 - /subversion/trunk/subversion/libsvn_fs/editor.c"
Next in thread: Greg Stein: "Re: svn commit: r1339892 -"
Reply: Greg Stein: "Re: svn commit: r1339892 -"

Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]