On Thu, 19 Feb 2015 11:33:01 +0100, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote: > Jeff King venit, vidit, dixit 18.02.2015 19:57: > > On Wed, Feb 18, 2015 at 10:47:16AM -0800, Junio C Hamano wrote: > > > >>> It seems like we could use > >>> > >>> (cd src && tar cf - .) | (cd dst && tar xf -) > >>> > >>> here as a more portable alternative. I don't think we can rely on rsync > >>> being everywhere. > >> > >> Thanks; I wasn't even aware that we used rsync in our tests. We > >> certainly do not want to rely on it. > > > > I don't think we do. > > > > Grepping for rsync in t/, it is mentioned in three places: > > > > 1. In t1509, we use it, but that test script does not run unless you > > set a bunch of environment variables to enable it. > > > > 2. In a sample patch for t4100. Obviously this one doesn't execute. :) > > > > 3. In t5500, to test "rsync:" protocol supported. This is behind a > > check that we can run rsync at all (though it does not properly use > > prereqs or use the normal "skip" procedure). > > > >> Why not "cp -r src dst", though? > > > > I was assuming that the "-P" in the original had some purpose. My "cp > > -r" does not seem to dereference symlinks, but maybe there is something > > I am missing. > > > > -Peff > > There's a symlink in sub that needs to be preserved. > > I'm cooking up a mini-series covering tar/cp -P so far and hopefully the > JP encodings later. Do I understand correctly that for Merijin's use Merijn, no second j. You can also call me Tux, as that is what the perl people do just because of that :) > case on HP-UX, we want > > - as few extra tools (GNU...) as possible for the run time git > - may get a few more tools installed to run the test You can require as many GNU tools for testing as you like: I'll install them. I just need to be sure they are not required runtime. (tar, cp) > I still don't have a clear picture of the iconv situation: Does your > iconv library require OLD_ICONV to compile? No > Is there a reason you want to disable it? Yes, if I build a package/depot, and the package depends on iconv, it is highly likely to fail on the client side after installation, as I do not control the version of iconv/libiconv installed. As HP does not have libiconv installed by default, I have experienced many tools to be unusable after installation because of that dependency. Another reason is that I built 64bitall, as my CURl and SSL environment is 64bitall for every other project on these systems (including Oracle related, which *only* ships 64bit objects on HP-UX) and the OpenSource repos for HP-UX only ship 32bit software (sad, but true). That implies that I cannot require libiconv.so to be present on the client side. I'd like my git to be as standalone as possible > Failing so many tests with NO_ICONV is certainly not ideal, but I'm not > sure we should care to protect so many tests with a prerequisite. How feasible is it to isolate those tests into separate test files that people that know to not use e.g. Asian can safely ignore them? > Michael -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Attachment:
pgplZAFjMg7dX.pgp
Description: OpenPGP digital signature