Imported Upstream version 0.9.7

Release 0.9.7.

Add porcelain 'daemon'.

Remove dul-daemon script, and replace with 'dulwich daemon'.

Add some tests for FileSystemBackend and DictBackend.

Remove --backend option from dulwich.server.main.

Add default values for outstreams in dulwich.porcelain.

Update NEWS.

Fix logic for extra adds of identical files.

Additionally, add a test.

Move the swift backend to dulwich/contrib.

Subcommands for initializing repositories on swift are now available
from the dulwich.contrib.swift module. In the future, we could
expose this functionality as a dulwich-swift script. The main reason
I haven't done this yet is to keep it clear that this script is in
contrib.

Openstack Swift backend support for bare repositories

This patch adds a new SwiftRepo object that inherits of
BaseRepo. The SwiftRepo object knows how to deal with
git repositories stored on an Openstack object storage
Swift.

Regular filesystems are the defacto backend for Git
repositories but suffers of some limitations in term of
availability and scalability. Using Swift as backend, Git
objects are duplicated in multiple replica, that improves a lot
the disponibity of your repositories, avoids the downtime
due to infrastructure maintenance and also avoids the need to
configure backups. Extending a regular filesystem where
your repositories are stored can be risky and can leads to
downtime. With Swift as backend, extending the storage size
is transparent.

For more details have a look to the README.swift file
provided by this patch.

Cherry-pick addition of --listen_address/--port argument from dulwich.server from a3be3876043e6bf14617a5584287de1e099dcabf.

Disable test_delta_large_object for the moment, since it is slow.

compat/test_pack: add test that proves large copies in a delta encode correctly

Change-Id: I1a6104344cd960c62273539546cf1581510707f3

Update NEWS.

compat/test_pack: add test that proves we correctly handle medium-sized objects

What I mean by "medium" in this case is that they're big enough to
require three bytes worth of length information in a copy operation,
but not big enough to require decomposing a copy operation into
multiple sequential copy operations.

Change-Id: I82c28bf8bae5c5c9ed06b79f7380bcdcf4c501e3

For the moment, keep deltification disabled - but add a flag to enable it.

pack.write_pack_objects: when packing, actually build deltas

This results in producing smaller packs. Includes a test that verifies
the resulting pack contains a delta and passes git-verify-pack's
checks.

Change-Id: I63f875cfe412ad727bc1364e3ed0a2b1d7214260

compat/test_pack: extract parsing of git-verify-pack output

A future test will want to reuse this same logic.

Change-Id: Icd36632331a514479cf8a89cdb0932a9eaf57e08

pack.write_pack_data: when writing OFS_DELTA entries, write correct offset

The old code wrote the OFS_DELTA offset as the offset from the start
of the pack file, which is
wrong. git.git/Documentation/technical/pack-format.txt states that the
offset is the number of bytes before the current object header that
the base object header starts, which is what we now write.

A future patch will exercise this code by enabling the writing of
deltas during packing.

Change-Id: Ie8431339e4ca3a6cc4e1969b90150b7a6e464d4c

Add tests for encode functions.

pack.create_delta: fix copy operations that are larger than 2^24 bytes

This correctly decomposes copies of sequences longer than 2^24 into
smaller copy operations, so that really big blobs in a repository
don't result in corrupt packs.

Note that difflib.SequenceMatcher is worst-case O(n^2) on its input,
so this is very slow. We may want to add an optional parameter to the
packing code that specifies a maximum size to deltify (beyond that
size we'd just include fulltexts in the packfile.)

This will be tested by a follow-up change after we enable
deltification in our pack-building code, as the easiest way to prove
this works correctly involves building a pack and feeding it to
git-verify-pack.

Change-Id: Ic30fa433a2f3b88ddb1aacfe4788dbd47b2e4490

pack.create_delta: correctly encode copy operations up to 2^24 in size

At present we still produce incorrect results for operations larger
than this size. That defect will be fixed in a follow-up to this
change.

Change-Id: Id63b500ae514caa4339063cde2d6486309a8a056

pack.create_delta: rename a couple of variables to make the code clearer

Change-Id: I5fed216800445277d6e069e0b20051006330d405

pack.create_delta: move encode_size to not be a nested function

No functional change, just tidies things up a little bit.

Change-Id: I48810dec9788584812dabe36976de60d24fce498

pack: enhance docstring on deltify_pack_objects

Change-Id: If208d523b3d7bb4d83f7ded2fec47d5c1052bbf0

Add .gitattributes files to force fast-export data for tests to checkout with lf line endings.

Signed-off-by: Jelmer Vernooij <jelmer@samba.org>

Skip side-band-64k TCP server tests on windows if cgit not >= 1.9.3.

Signed-off-by: Jelmer Vernooij <jelmer@samba.org>

Merge branch 'octal-numbers' of git://github.com/garyvdm/dulwich

Add write_error argument to GitClient.archive().

Skip porcelain archive test when c git is not available.

Merge branch 'python3-close-files' of git://github.com/garyvdm/dulwich

News entry for file object closing.

Close file objects.

Close files for Pack objects.

Close files for Protocol objects.

Fix another potential XSS issue, and add test for the previous one.

Fix octal number literals.

Signed-off-by: Jelmer Vernooij <jelmer@samba.org>

Merge branch 'service-name-xss' of git://github.com/durin42/dulwich

web: don't echo back invalid service names

This prevents potential XSS attacks, which could have injected
arbitrary content under a domain by echoing back the unsupported
service name.

Use byte literal in test_pack.py so that module can be imported in py3.

Alter itertools import statement so that 2to3 fixes it.

Use 2to3 in setup.py.

Fix octal number literals.

Merge branch 'py3k' of git://github.com/Ormod/dulwich

index: Fix IndexEntry to not include name.

NEWS entry for python3 changes.

Use for loop instead of map.

Stop using more deprecated test methods.

Add 'make before-push' target.

Add pep8 make target and fix some pep8ness.

Add 'flakes' target invoking pyflakes, and fix some pyflakes warnings.

Remove pylint config.

Add dulwich.greenthreads module.

setup: Make setup.py also work on py3k on OS X

py3k: These need to return a value since in Py3k they're no longer void

Python 2.x shouldn't care about it though the signature is void there.

As exhibited in error:

dulwich/_diff_tree.c:449:2: error: non-void function 'init_diff_tree'
should return a value [-Wreturn-type]

py3k: Go through all uses of itertools and make them work on py3k

tests: Change assertEquals to be py3k compatible assertEqual.

Signed-off-by: Jelmer Vernooij <jelmer@samba.org>

In Protocol.read_pkt_line, assert the length of the data read matches the length prefix.

Correctly handle binascii.Error.

Use for loop instead of map when not iterating.

In PY3, map returns an iterator, so the funcion never gets called.

Use assertEqual rather than assertEquals as the latter is deprecated.

Make next methods available as __next__.

Use int division `//` insted of float division `/`.

Use io module instead of file.

Fix octal literals.

print(): Switch from statement to funtion.

Use the print() function in Makefile.

Use the print() function rather than the print statement in the
Makefile.

Move logic for creating blog from path to dulwich.index.

Add test to make sure unmodified files don't show up in get_unstaged_changes.

Add porcelain for 'status'.

Use namedtuple for index entry.

Bugfix: cmd_reset could not determine the mode

Fix copy-&-paste errors in command line interface.

Fix typo in tutorial.

fix twisted output

Remove long lines.

Update NEWS.

Add symbolic link support to Repo.stage().

Update NEWS.

Fix tests dependent on hash ordering.

Start on 0.9.7.

Imported Upstream version 0.9.6

Release 0.9.6.

Update MANIFEST.in.

Convert README to markdown.

Only reload new pack files, and discard old ones when updating pack
cache.

Fix leak when pack cache is rebuilt.

Update NEWS, fix test.

DeltaChainIterator: fix a corner case where an object is inflated as an object already in the repository. Fixes #135.

Fix formatting for pydoctor.

Update NEWS.

Merge branch 'github-fix' of git://github.com/sid0/dulwich

Mention python3 related compatibility fixes.

Don't wait for EOF in _handle_receive_pack_tail

This is the same as the previous commit, except it makes receive-pack (i.e. git
push) to a GitHub repository work again.

Don't wait for EOF in _handle_upload_pack_tail with side-band-64k

As of Sat, 12 Apr 2014 08:46:15 +0000, cloning, fetching or receiving a pack
from a GitHub repository with dulwich results in a hang. For example, the
command:

    bin/dulwich clone git@github.com:jelmer/dulwich.git

produces the following output:

    Reusing existing pack: 12675, done.
    Counting objects: 1408, done.
    Compressing objects: 100% (891/891), done.

and then hangs indefinitely.

This commit and the next one aim to fix that.

The indefinite hang is because _handle_upload_pack_tail waits for an EOF from
the server that never arrives. With canonical Git, both the client and the
server disconnect after the fetch is completed. With canonical Git servers,
Dulwich works fine since the server will disconnect. However, GitHub seems to be
running a non-canonical implementation of Git, which waits for the client to
disconnect. That works fine with canonical Git clients but not with Dulwich.

Is this a bug in the server or the client? This is arguable, but it's reasonable
to assume that no matter how the server acts, the client should disconnect
without waiting for an EOF. Why? Quoting Git's
Documentation/technical/pack-protocol.txt,

    After reference and capabilities discovery, the client can decide to
    terminate the connection by sending a flush-pkt, telling the server it can
    now gracefully terminate, and disconnect, when it does not need any pack
    data. This can happen with the ls-remote command, and also can happen when
    the client already is up-to-date.

This indicates that in general for stateful transports (i.e. not HTTP), the
client is responsible the lifecycle of the connection. The protocol
documentation doesn't explicitly specify what happens after the client fetches a
pack, but I think it's logical to extrapolate similar behaviour.

This patch causes the Dulwich client to disconnect right after the fetch is
complete, which menas that the above clone command completes correctly. Clones
from canonical Git servers continue to work as well.

It is pretty hard to write a test for this patch because the canonical Git
server doesn't behave this way and we don't have access to the GitHub server.

This was originally reported as a bug in hg-git, which uses Dulwich: see
https://bitbucket.org/durin42/hg-git/issue/104/hangs-after-total. Thanks to
John S Long and Marco Molteni for debugging this issue over there.

Merge branch 'python3' of git://github.com/garyvdm/dulwich

Remove monkeypatch for older versions of urlparse.uses_netloc.

Signed-off-by: Jelmer Vernooij <jelmer@samba.org>

Remove ShutdownServerMixIn now that we don't support 2.4 & 2.5.

Signed-off-by: Jelmer Vernooij <jelmer@samba.org>

Use next(iter) instead of iter.next()

Use email.parser rather than rfc822.