tests/test-lfs-bundle.t
author Matt Harbison <matt_harbison@yahoo.com>
Mon, 28 Jan 2019 21:35:06 -0500
changeset 41440 1bc01490178a
parent 37439 556984ae0005
child 44379 ca82929e433d
permissions -rw-r--r--
lfs: explicitly add the Content-Length header when uploading blobs, for py3 This was the reason for test-lfs-test-server.t#git-server complaining about an "invalid byte in chunk length". For some reason if this isn't explicitly added, py3.7.1 is adding `transfer-encoding: chunked` as well as `Content-length: x`. Wireshark flagged this as malformed. However, if this is set, it doesn't bother with `transfer-encoding`. Before this patch with py3: PUT /objects/31cf46fbc4ecd458a0943c5b4881f1f5a6dd36c53d6167d5b69ac45149b38e5b HTTP/1.1 Accept-Encoding: identity Content-length: 12 accept: application/vnd.git-lfs content-type: application/octet-stream host: localhost:20062 transfer-encoding: chunked user-agent: git-lfs/2.3.4 (Mercurial 4.9rc0+149-7eb7637e34bf) Before this patch with py27: PUT /objects/31cf46fbc4ecd458a0943c5b4881f1f5a6dd36c53d6167d5b69ac45149b38e5b HTTP/1.1 Accept-Encoding: identity accept: application/vnd.git-lfs content-type: application/octet-stream content-length: 12 host: localhost:20062 user-agent: git-lfs/2.3.4 (Mercurial 4.9rc0+149-7eb7637e34bf+20190128) With this patch and py3, the content is the same as the py27 example. RFC2616 says to ignore `Content-Length` if `Transfer-Encoding` is present, so maybe there's nothing to do in the hg-server side (though I'm not sure which it is using if presented both). Maybe chunked encoding is better to do? If someone knows how to suppress the `Content-Length`, we can try that instead.

In this test, we want to test LFS bundle application on both LFS and non-LFS
repos.

To make it more interesting, the file revisions will contain hg filelog
metadata ('\1\n'). The bundle will have 1 file revision overlapping with the
destination repo.

#  rev      1          2         3
#  repo:    yes        yes       no
#  bundle:  no (base)  yes       yes (deltabase: 2 if possible)

It is interesting because rev 2 could have been stored as LFS in the repo, and
non-LFS in the bundle; or vice-versa.

Init

  $ cat >> $HGRCPATH << EOF
  > [extensions]
  > lfs=
  > drawdag=$TESTDIR/drawdag.py
  > [lfs]
  > url=file:$TESTTMP/lfs-remote
  > EOF

Helper functions

  $ commitxy() {
  > hg debugdrawdag "$@" <<'EOS'
  >  Y  # Y/X=\1\nAAAA\nE\nF
  >  |  # Y/Y=\1\nAAAA\nG\nH
  >  X  # X/X=\1\nAAAA\nC\n
  >     # X/Y=\1\nAAAA\nD\n
  > EOS
  > }

  $ commitz() {
  > hg debugdrawdag "$@" <<'EOS'
  >  Z  # Z/X=\1\nAAAA\nI\n
  >  |  # Z/Y=\1\nAAAA\nJ\n
  >  |  # Z/Z=\1\nZ
  >  Y
  > EOS
  > }

  $ enablelfs() {
  >   cat >> .hg/hgrc <<EOF
  > [lfs]
  > track=all()
  > EOF
  > }

Generate bundles

  $ for i in normal lfs; do
  >   NAME=src-$i
  >   hg init $TESTTMP/$NAME
  >   cd $TESTTMP/$NAME
  >   [ $i = lfs ] && enablelfs
  >   commitxy
  >   commitz
  >   hg bundle -q --base X -r Y+Z $TESTTMP/$NAME.bundle
  >   SRCNAMES="$SRCNAMES $NAME"
  > done

Prepare destination repos

  $ for i in normal lfs; do
  >   NAME=dst-$i
  >   hg init $TESTTMP/$NAME
  >   cd $TESTTMP/$NAME
  >   [ $i = lfs ] && enablelfs
  >   commitxy
  >   DSTNAMES="$DSTNAMES $NAME"
  > done

Apply bundles

  $ for i in $SRCNAMES; do
  >   for j in $DSTNAMES; do
  >     echo ---- Applying $i.bundle to $j ----
  >     cp -R $TESTTMP/$j $TESTTMP/tmp-$i-$j
  >     cd $TESTTMP/tmp-$i-$j
  >     if hg unbundle $TESTTMP/$i.bundle -q 2>/dev/null; then
  >       hg verify -q && echo OK
  >     else
  >       echo CRASHED
  >     fi
  >   done
  > done
  ---- Applying src-normal.bundle to dst-normal ----
  OK
  ---- Applying src-normal.bundle to dst-lfs ----
  OK
  ---- Applying src-lfs.bundle to dst-normal ----
  OK
  ---- Applying src-lfs.bundle to dst-lfs ----
  OK