Philip Martin writes:
> State 3: after A/B to A/B2 then A to A2
> op_depth local_relpath presence moved_here moved_to
> 0A normalA2
> 0A/BnormalA2/B
Typo, moved_to should be A2/B2.
> 1A base-
"Bert Huijben" writes:
> The only case where you would want to track those moves, is when they are
> also stored in a different place in BASE.
Lets consider moves that do have a base node. I'm trying to determine
what is the correct behaviour for the tests nested_moves_child_first and
nested_mo
Julian Foad writes:
>> Now consider a further merge, it will produce a tree conflict it it
>> attempts to modify X/Y, the modifications should go into X/Z. If we
>> record the Y->Z move then merge can avoid the tree conflict.
>
> Precisely -- agreed.
Another example, see move_on_move, the new t
Philip Martin wrote:
> Julian Foad writes:
>> Is there a bit of terminology mix-up here between "add" and "copy"?
>
> I don't think so?
OK. I was a bit confused after Bert said "I don't know how you want to record
in the repository that a node is new (added) and moved to a different place in
On 12/07/2011 08:58 AM, Julian Foad wrote:
> Merge currently never performs an add in the "new creation" sense; an add
> in the merge source becomes a copy in the merge target.
...except when doing a foreign repository merge.
--
C. Michael Pilato
CollabNet <> www.collab.net <> Distribut
Julian Foad writes:
> Is there a bit of terminology mix-up here between "add" and "copy"?
I don't think so?
> I think it would help clarity if we took a lead from Greg in reserving
> the word "add" for creation of a new item with no history, and
> otherwise saying "copy" or "move" as appropriat
Philip wrote:
> "Bert Huijben" writes:
>>> That's relatively simple but it raises one big question: is the base
>>> node the right place to record moved_to? What about nodes without base
>>> nodes? When X is the child of a copied directory that is not a
>>> replacement then X will not have a
Philip Martin writes:
> Or suppose I merge a revision that adds X containing X/Y, then I merge
> (with a new merge-aware merge) another revision that moves X/Y to X/Z,
Typo: "merge-aware merge" was supposed to be "move-aware" merge.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.co
"Bert Huijben" writes:
>> That's relatively simple but it raises one big question: is the base
>> node the right place to record moved_to? What about nodes without base
>> nodes? When X is the child of a copied directory that is not a
>> replacement then X will not have a base node, but if the
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: woensdag 7 december 2011 13:13
> To: dev@subversion.apache.org
> Subject: Move tracking and NODES.moved_to/moved_here
>
> This is about tracking local, uncommitted moves in thw
This is about tracking local, uncommitted moves in thw working copy.
Trunk has begun to use the NODES columns moved_to and moved_here that
are unused in 1.7. I'm a bit confused about how it is supposed to work.
moved_to is a relpath while moved_here is treated as a boolean, with
repos_path provid
11 matches
Mail list logo
