On 13 March 2015, Julian Foad wrote:
> Dear fans of move tracking,
> I heartily invite you to help by playing with 'svnmover'. Can you have
> a go and see what it can do? It's quite fun to play with (in a nerdy
> way :-)
One unimplemented bit you might come across is 'svnmover merge'
doesn't try to merge file content. It reports a conflict if file
content (text and/or props) needs merging. That's simply because it
isn't directly relevant to the move logic so I didn't bother to
implement it yet; we can use directories instead of files, or files
without content changes, to test the move logic. Please feel free to
add text and props merging code near the comment
/* ### Need not conflict if can merge props and text separately. */
in svnmover.c:element_merge(), if you fancy doing so.
Anyone tried or planning to try this, yet?
> To get it, build the 'move-tracking-2' branch and look in
> 'subversion/svnmover/svnmover' -- it's a sibling to 'svn' and
> It's fairly easy to pick up as you go along. There's a transcript
> below, as an example. You can also see in the IRC history  where I
> guided Brane through playing with it for the first time.
> You can try
> - doing renames/moves (using 'mv PATH1 PATH2')
> - merging those changes onto another branch ('merge FROM TO YCA')
> - visualize what's happening ('branches PATH', 'ls PATH', 'ls-br-r')
> - type 'help' to see usage message
> You should find that it copes perfectly with renames inside renames, and so on.
> Do please share any thoughts or questions you have --
> * about the model
> * do you grok the way moves work in svnmover?
> * any new feature 'svnmover' should have to help with experimenting?
> I believe we can build a move-tracking design for Subversion. This
> stage is not trying to give the final answer, it is squarely aimed at
> exploring and understanding how it could and should work. So I need
> *your* input, please, if you can spare some thought cycles and
> experimentation cycles.
> Here's an example transcript.
Received on 2015-03-17 16:18:45 CET