You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by ph...@apache.org on 2012/03/14 18:13:42 UTC
svn commit: r1300647 -
/subversion/branches/multi-layer-moves/subversion/libsvn_wc/wc_db.c
Author: philip
Date: Wed Mar 14 17:13:42 2012
New Revision: 1300647
URL: http://svn.apache.org/viewvc?rev=1300647&view=rev
Log:
On multi-layer-move branch, remove an excessively strict check and allow
a node to be both moved_to and moved_here. copy_tests 45 and 46 move a
node and move it back and expect the result to be a replace; recording
the moves for such a case seems reasonable.
All regression tests now pass on the branch.
* subversion/libsvn_wc/wc_db.c
(read_children_info): Remove a check.
Modified:
subversion/branches/multi-layer-moves/subversion/libsvn_wc/wc_db.c
Modified: subversion/branches/multi-layer-moves/subversion/libsvn_wc/wc_db.c
URL: http://svn.apache.org/viewvc/subversion/branches/multi-layer-moves/subversion/libsvn_wc/wc_db.c?rev=1300647&r1=1300646&r2=1300647&view=diff
==============================================================================
--- subversion/branches/multi-layer-moves/subversion/libsvn_wc/wc_db.c (original)
+++ subversion/branches/multi-layer-moves/subversion/libsvn_wc/wc_db.c Wed Mar 14 17:13:42 2012
@@ -7522,15 +7522,6 @@ read_children_info(void *baton,
/* Moved-here can only exist at op_depth > 0. */
child_item->info.moved_here = svn_sqlite__column_boolean(stmt, 20);
-
- /* Sanity check: A child is either moved-here, or moved-away. */
- if (child_item->info.moved_here && moved_to_relpath)
- return svn_error_createf(SVN_ERR_WC_CORRUPT, NULL,
- _("The node '%s' has ambiguous move information"),
- svn_dirent_local_style(svn_dirent_join(wcroot->abspath,
- child_relpath,
- scratch_pool),
- scratch_pool));
}
SVN_ERR(svn_sqlite__step(&have_row, stmt));
Re: Possible WC format bump
Posted by Greg Stein <gs...@gmail.com>.
On Mar 15, 2012 9:22 AM, "C. Michael Pilato" <cm...@collab.net> wrote:
>
> On 03/14/2012 02:28 PM, Philip Martin wrote:
> > "C. Michael Pilato" <cm...@collab.net> writes:
> >> What happens in the opposite case -- that is, when you have a
> >> branch-based working copy and you move something, then use a stable
> >> 1.7 client to access it?
> >
> > The stable 1.7 client will ignore the moved-to/here completely and treat
> > the move as copy+delete.
> >
> > Current trunk will ignore most of moved-to/here create by the branch and
> > will usually treat the move as copy+delete, but it's not ignoring it
> > like 1.7 so I suppose some operations may fail. Similarly while the
> > branch will ignore most moved-to/here created by current trunk I can't
> > be certain it will ignore it in all cases.
>
> Thanks. Sounds like it's fine to just reintegrate without the format
bump.
Already done. r1300933 :-)
Re: Possible WC format bump
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 03/14/2012 02:28 PM, Philip Martin wrote:
> "C. Michael Pilato" <cm...@collab.net> writes:
>> What happens in the opposite case -- that is, when you have a
>> branch-based working copy and you move something, then use a stable
>> 1.7 client to access it?
>
> The stable 1.7 client will ignore the moved-to/here completely and treat
> the move as copy+delete.
>
> Current trunk will ignore most of moved-to/here create by the branch and
> will usually treat the move as copy+delete, but it's not ignoring it
> like 1.7 so I suppose some operations may fail. Similarly while the
> branch will ignore most moved-to/here created by current trunk I can't
> be certain it will ignore it in all cases.
Thanks. Sounds like it's fine to just reintegrate without the format bump.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Possible WC format bump
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Mar 14, 2012 at 16:01, Stefan Sperling <st...@elego.de> wrote:
>...
> This only affects working copies which contain moves recorded by
> a trunk svn client. Once the branch is reintegrated, those moves
> will stop working as expected.
>
> Given that the current target audience of trunk clients is reading
> this list, I don't think a format bump is required.
Before we released 1.7, it was handy to keep bumping the wc format for
changes. But now that 1.7 *has* been released, format bumps come with
a lot of baggage. It immediately disables any 1.7 clients from working
on a 1.8 working copy. We really should avoid that unless we find a
true benefit against that cost.
> Anyone who has working copies with local changes involving moves will
> have to either commit or revert those changes before using a trunk
> client that contains the changes currently still sitting on the
> multi-layer-moves branch. I don't think this is a big problem.
>
> Whether we'll bump the format for 1.8 release is a separate issue.
Agreed, and agreed.
So far, we haven't found a need for a bump, and maybe we could keep it
that way for 1.8. We already put people through the update wringer for
1.7... maybe let the dust settle a bit :-P
Cheers,
-g
Re: Possible WC format bump
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Mar 14, 2012 at 06:28:40PM +0000, Philip Martin wrote:
> "C. Michael Pilato" <cm...@collab.net> writes:
>
> > On 03/14/2012 01:58 PM, Philip Martin wrote:
> >> $ svn mv wc/A/g wc/g # using trunk
> >> A wc/g
> >> D wc/A/f
> >> $ svn st wc # using trunk
> >> D wc/A/f
> >> > moved to wc/g
> >> A + wc/g
> >> > moved from wc/A/f
> >>
> >> If we now use the branch on that working copy:
> >>
> >> $ svn st wc
> >> D wc/A/f
> >> A + wc/g
> >>
> >> The moved-to/from is lost, a bit like 1.7 which simply doesn't consider
> >> moved-to/from
> >
> > What happens in the opposite case -- that is, when you have a
> > branch-based working copy and you move something, then use a stable
> > 1.7 client to access it?
>
> The stable 1.7 client will ignore the moved-to/here completely and treat
> the move as copy+delete.
>
> Current trunk will ignore most of moved-to/here create by the branch and
> will usually treat the move as copy+delete, but it's not ignoring it
> like 1.7 so I suppose some operations may fail. Similarly while the
> branch will ignore most moved-to/here created by current trunk I can't
> be certain it will ignore it in all cases.
This only affects working copies which contain moves recorded by
a trunk svn client. Once the branch is reintegrated, those moves
will stop working as expected.
Given that the current target audience of trunk clients is reading
this list, I don't think a format bump is required.
Anyone who has working copies with local changes involving moves will
have to either commit or revert those changes before using a trunk
client that contains the changes currently still sitting on the
multi-layer-moves branch. I don't think this is a big problem.
Whether we'll bump the format for 1.8 release is a separate issue.
Re: Possible WC format bump
Posted by Philip Martin <ph...@wandisco.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
> On 03/14/2012 01:58 PM, Philip Martin wrote:
>> $ svn mv wc/A/g wc/g # using trunk
>> A wc/g
>> D wc/A/f
>> $ svn st wc # using trunk
>> D wc/A/f
>> > moved to wc/g
>> A + wc/g
>> > moved from wc/A/f
>>
>> If we now use the branch on that working copy:
>>
>> $ svn st wc
>> D wc/A/f
>> A + wc/g
>>
>> The moved-to/from is lost, a bit like 1.7 which simply doesn't consider
>> moved-to/from
>
> What happens in the opposite case -- that is, when you have a
> branch-based working copy and you move something, then use a stable
> 1.7 client to access it?
The stable 1.7 client will ignore the moved-to/here completely and treat
the move as copy+delete.
Current trunk will ignore most of moved-to/here create by the branch and
will usually treat the move as copy+delete, but it's not ignoring it
like 1.7 so I suppose some operations may fail. Similarly while the
branch will ignore most moved-to/here created by current trunk I can't
be certain it will ignore it in all cases.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Possible WC format bump
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 03/14/2012 01:58 PM, Philip Martin wrote:
> $ svn mv wc/A/g wc/g # using trunk
> A wc/g
> D wc/A/f
> $ svn st wc # using trunk
> D wc/A/f
> > moved to wc/g
> A + wc/g
> > moved from wc/A/f
>
> If we now use the branch on that working copy:
>
> $ svn st wc
> D wc/A/f
> A + wc/g
>
> The moved-to/from is lost, a bit like 1.7 which simply doesn't consider
> moved-to/from
What happens in the opposite case -- that is, when you have a branch-based
working copy and you move something, then use a stable 1.7 client to access it?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Possible WC format bump
Posted by Philip Martin <ph...@wandisco.com>.
philip@apache.org writes:
> Author: philip
> Date: Wed Mar 14 17:13:42 2012
> New Revision: 1300647
>
> URL: http://svn.apache.org/viewvc?rev=1300647&view=rev
> Log:
> On multi-layer-move branch, remove an excessively strict check and allow
> a node to be both moved_to and moved_here. copy_tests 45 and 46 move a
> node and move it back and expect the result to be a replace; recording
> the moves for such a case seems reasonable.
>
> All regression tests now pass on the branch.
Current trunk records moved-to/from data, with moved-to in the base
nodes in wc.db. It does this using the same DB schema as 1.7 and there
has been no wc format bump since 1.7. This means both 1.7 and trunk
clients can operate on the same working copy. 1.7 doesn't record
moved-to/from, and ignores and moved-to/from recorded by trunk treating
moves as copy+delete.
The existing trunk base node system has problems that are fixed by the
multi-layer-moves branch. It is now time to reintegrate the branch but
it is not compatible with the existing trunk moved-to/from storage,
although no schema change is involved.
$ svn mv wc/A/g wc/g # using trunk
A wc/g
D wc/A/f
$ svn st wc # using trunk
D wc/A/f
> moved to wc/g
A + wc/g
> moved from wc/A/f
If we now use the branch on that working copy:
$ svn st wc
D wc/A/f
A + wc/g
The moved-to/from is lost, a bit like 1.7 which simply doesn't consider
moved-to/from
The question I have is whether the branch should bump the wc format. I
would not go as far as writing code to migrate the moved-to/from, the
code would simply throw an error during upgrade if any base-node moves
were present.
In general wc format bumps are cheap, but this is the first format bump
since 1.7 which makes it more expensive: it stops the stable client
being able to access trunk working copies. I've been assumming that
there will a format bump at some time before 1.8, perhaps it should be
now?
--
Philip