On Tue, Jul 12, 2011 at 00:02, William A. Rowe Jr. <wr...@rowe-clan.net> wrote: >... >> Which should be the combined revert of >> >> http://svn.apache.org/viewvc?view=revision&revision=1143225 >> http://svn.apache.org/viewvc?view=revision&revision=1143222 >> http://svn.apache.org/viewvc?view=revision&revision=1143221 >> http://svn.apache.org/viewvc?view=revision&revision=1141203 >> http://svn.apache.org/viewvc?view=revision&revision=1141201 >> http://svn.apache.org/viewvc?view=revision&revision=1140075 >> http://svn.apache.org/viewvc?view=revision&revision=1140069 >> http://svn.apache.org/viewvc?view=revision&revision=1130186 >> http://svn.apache.org/viewvc?view=revision&revision=1131393 >> http://svn.apache.org/viewvc?view=revision&revision=1129956 >> http://svn.apache.org/viewvc?view=revision&revision=1129891 >> http://svn.apache.org/viewvc?view=revision&revision=1129886 >> http://svn.apache.org/viewvc?view=revision&revision=1129808 > > Sorry, I don't see applying a mega-revert. Either piecemeal > or wholesale svn cp's from pre-1129808 seems more sensible. > The later is more legible in svn, because re-applying the > commits with proper attribution would be messy.
'svn cp' can be dangerous... you may wipe out other, unrelated changes. >From a version control aspect, you also lose the information that the (above) revisions were reverse-merged (aka reverted). But I would simply state that is a pedantic detail, and the revert process should use whatever is easiest. If you go with 'svn cp', then just check the logs on the target files to ensure you don't lose unrelated changes. Cheers, -g
