On 7/12/2011 2:12 PM, Greg Stein wrote: > 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.
Absolutely, I understand that. Each specific unrelated change will be recommitted with all original attributions and svn references. The vast majority of commits are ldap changes. I will not be svn cp'ing the entire project, only targeted modules/ldap/ and specific include/ and build/ files. That's why I need reliable connectivity to apply this 'overwrite' back to the old state of svn, while preserving the changes to other parts of httpd/trunk/ >>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. +1, concur. Guenter et al, are the ldap changes more than 50% ldap changes, or fewer? I'd go with the path of least resistance on NWGNUxxx history.
