Issue 5 in svnbook: Document svnmucc

[svnbook at googlecode.com]

Comment #6 on issue 5 by markus.k... at gmail.com: Document svnmucc
http://code.google.com/p/svnbook/issues/detail?id=5

I think that there really ought to be an example of how to achieve  
transaction safety when using "svnmucc put", otherwise only few will  
understand how to use option -r in practice to implement transactions that  
edit files safely. The example transaction could show something along the  
lines of

   $ latest=`svnlook youngest path-to-repos`
   $ svn cat -r $latest $url | sed -e 's/old/new/' | svnmucc put -r $latest  
$url

That is it should

   - look up what the latest version is
   - get a copy of that version
   - edit it
   - put it back while checking for (and ideally even handling) conflicts

all without using the file system.

Also, please don't forget to document, what happens in case of a conflict,  
and what access users of "svnmucc put -r" have to any of the mechanics for  
resolving a conflict.

There may even still be a few crucial bits missing to make such an example  
really neat, robust and impressive:

- a URL based version of "svnlook youngest $repo-path" (e.g. "svn youngest  
$url"), as otherwise the example needs to include clumsy parsing code for  
the output of "svn info --xml $url".

- "svnmucc put -r $latest -n ..." command-line options to resolve conflicts  
in a non-interactive way, along the lines of the interactive (df)  
diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, etc. options.

While a simple "sed-based" edit as above is easily repeated in case of a  
conflict (i.e., just put the above example inside a loop to repeat until it  
succeeds), an edit might also have been produced by a human, who might have  
worked for an hour to edit a file in a web form. In that latter case,  
access to conflict resolution mechanisms would be very useful.