view tests/test-pull-r.t @ 37766:925707ac2855

lfs: add the 'Authorization' property to the Batch API response, if present The client copies all of these properties under 'header' to the HTTP Headers of the subsequent GET or PUT request that it performs. That allows the Basic HTTP authentication used to authorize the Batch API request to also authorize the upload/download action. There's likely further work to do here. There's an 'authenticated' boolean key in the Batch API response that can be set, and there is an 'LFS-Authenticate' header that is used instead of 'WWW-Authenticate'[1]. (We likely need to support both, since some hosting solutions are likely to only respond with the latter.) In any event, this works with SCM Manager, so there is real world benefit. I'm limiting the headers returned to 'Basic', because that's all the lfs spec calls out. In practice, I've seen gitbucket emit custom header content[2]. [1] https://github.com/git-lfs/git-lfs/blob/master/docs/api/batch.md#response-errors [2] https://github.com/gitbucket/gitbucket/blob/35655f33c7713f08515ed640ece0948acd6d6168/src/main/scala/gitbucket/core/servlet/GitRepositoryServlet.scala#L119
author Matt Harbison <matt_harbison@yahoo.com>
date Fri, 06 Apr 2018 11:13:47 -0400
parents edf52be98978
children bd7b2c8d06cc
line wrap: on
line source

  $ hg init repo
  $ cd repo
  $ echo foo > foo
  $ hg ci -qAm 'add foo'
  $ echo >> foo
  $ hg ci -m 'change foo'
  $ hg up -qC 0
  $ echo bar > bar
  $ hg ci -qAm 'add bar'

  $ hg log
  changeset:   2:effea6de0384
  tag:         tip
  parent:      0:bbd179dfa0a7
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     add bar
  
  changeset:   1:ed1b79f46b9a
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     change foo
  
  changeset:   0:bbd179dfa0a7
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     add foo
  
  $ cd ..

don't show "(+1 heads)" message when pulling closed head

  $ hg clone -q repo repo2
  $ hg clone -q repo2 repo3
  $ cd repo2
  $ hg up -q 0
  $ echo hello >> foo
  $ hg ci -mx1
  created new head
  $ hg ci -mx2 --close-branch
  $ cd ../repo3
  $ hg heads -q --closed
  2:effea6de0384
  1:ed1b79f46b9a
  $ hg pull
  pulling from $TESTTMP/repo2
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 2 changesets with 1 changes to 1 files
  new changesets 8c900227dd5d:00cfe9073916
  (run 'hg update' to get a working copy)
  $ hg heads -q --closed
  4:00cfe9073916
  2:effea6de0384
  1:ed1b79f46b9a

  $ cd ..

  $ hg init copy
  $ cd copy

Pull a missing revision:

  $ hg pull -qr missing ../repo
  abort: unknown revision 'missing'!
  [255]

Pull multiple revisions with update:

  $ hg pull -qu -r 0 -r 1 ../repo
  $ hg -q parents
  0:bbd179dfa0a7
  $ hg rollback
  repository tip rolled back to revision -1 (undo pull)
  working directory now based on revision -1

  $ hg pull -qr 0 ../repo
  $ hg log
  changeset:   0:bbd179dfa0a7
  tag:         tip
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     add foo
  
  $ hg pull -qr 1 ../repo
  $ hg log
  changeset:   1:ed1b79f46b9a
  tag:         tip
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     change foo
  
  changeset:   0:bbd179dfa0a7
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     add foo
  

This used to abort: received changelog group is empty:

  $ hg pull -qr 1 ../repo

Test race condition with -r and -U (issue4707)

We pull '-U -r <name>' and the name change right after/during the changegroup emission.
We use http because http is better is our racy-est option.


  $ echo babar > ../repo/jungle
  $ cat <<EOF > ../repo/.hg/hgrc
  > [hooks]
  > outgoing.makecommit = hg ci -Am 'racy commit'; echo committed in pull-race
  > EOF
  $ hg serve -R ../repo -p $HGPORT2 -d --pid-file=../repo.pid
  $ cat ../repo.pid >> $DAEMON_PIDS
  $ hg pull --rev default --update http://localhost:$HGPORT2/
  pulling from http://localhost:$HGPORT2/
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files (+1 heads)
  new changesets effea6de0384
  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ hg log -G
  @  changeset:   2:effea6de0384
  |  tag:         tip
  |  parent:      0:bbd179dfa0a7
  |  user:        test
  |  date:        Thu Jan 01 00:00:00 1970 +0000
  |  summary:     add bar
  |
  | o  changeset:   1:ed1b79f46b9a
  |/   user:        test
  |    date:        Thu Jan 01 00:00:00 1970 +0000
  |    summary:     change foo
  |
  o  changeset:   0:bbd179dfa0a7
     user:        test
     date:        Thu Jan 01 00:00:00 1970 +0000
     summary:     add foo
  

  $ cd ..
  $ killdaemons.py