Re: svnmover simulates a WC

You can't forget the most fun torture case for generalized move support that involves non-cyclic but directory hierarchy rearranging moves: (without branches) Files in directory tree: BranchRoot\A\B\C\d.txt BranchRoot\A\B\e.txt BranchRoot\A\g.txt BranchRoot\A\F\h.txt mv BranchRoot\A\B BranchRoot\

Re: Moves in FSFS

On a slightly different note I noticed this oddity in lib_fs_fs/dag.c from http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/dag.c?annotate=1517479 703jpieper849539if (is_parent_c

Re: Moves in FSFS

Move tracking can clearly make ones head spin. :) Brane: Could Julian and Stephan be asking about how to map between arbitrary revisions thinking of tree merge scenarios? That's what always gave me heart burn with the current Noderev behavior and envisioning real moves in Subversion. In thinking

Re: Design query: Ev2 and multiple moves

On Tue, Nov 8, 2011 at 6:22 AM, Julian Foad wrote: > Hi Bill. > > Let me see if I understand. > > You describe a procedure for converting a set of parallel renames into an > equivalent incremental sequence of renames.  That is, the input is a list of > N independent renames, where each "rename[i

Re: Design query: Ev2 and multiple moves

I just know folks are going to hate me for mentioning this, but. Tom Lord came up with a way to store/apply arbitrary rename applications against trees. Apparently my google-fu failed me tonight because I couldn't find the original reference/explanation. So bear with me as I recall the details

Re: diff-optimizations-tokens branch: I think I'm going to abandon it

Note: This email only tangentially relates to svn diff and more about reverse token scanning in general: As someone who has implemented suffix reverse token scanning before: * It simply isn't possible in DBCS code pages. Stick to byte only here.    SBCS and UTF-16 make reverse token stuff relativ