2011 ATP Challenger Guangzhou

2011 ATP Challenger Guangzhou
Date	14 – 20 March
Edition	2nd
Surface	Hard
Location	Guangzhou, China
Champions
Singles
	Uladzimir Ignatik
Doubles
	Michail Elgin / Alexandre Kudryavtsev

The 2011 ATP Challenger Guangzhou was a professional tennis tournament played on hard courts. It was the second edition of the tournament which was part of the 2011 ATP Challenger Tour. It took place in Guangzhou, China between 14 and 20 March 2011.

ATP entrants

Seeds

Country	Player	Rank¹	Seed
JPN	Go Soeda	109	1
SVK	Lukáš Lacko	119	2
BEL	Steve Darcis	129	3
RUS	Alexandre Kudryavtsev	144	4
GER	Matthias Bachinger	160	5
JPN	Tatsuma Ito	173	6
BLR	Uladzimir Ignatik	200	7
GER	Dominik Meffert	211	8

Rankings are as of March 7, 2011.

Other Entrants

The following players received wildcards into the singles main draw:

The following entrant has been granted a Special Exemption into the main draw:

Cedrik-Marcel Stebe

The following players received entry from the qualifying draw:

Champions

Singles

Uladzimir Ignatik def. Alexandre Kudryavtsev, 6–4, 6–4

Doubles

Michail Elgin / Alexandre Kudryavtsev def. Sanchai Ratiwatana / Sonchat Ratiwatana, 7–6(3), 6–3

gollark: The stages of git clone are: Receive a "pack" file of all the objects in the repo database Create an index file for the received pack Check out the head revision (for a non-bare repo, obviously)"Resolving deltas" is the message shown for the second stage, indexing the pack file ("git index-pack").Pack files do not have the actual object IDs in them, only the object content. So to determine what the object IDs are, git has to do a decompress+SHA1 of each object in the pack to produce the object ID, which is then written into the index file.An object in a pack file may be stored as a delta i.e. a sequence of changes to make to some other object. In this case, git needs to retrieve the base object, apply the commands and SHA1 the result. The base object itself might have to be derived by applying a sequence of delta commands. (Even though in the case of a clone, the base object will have been encountered already, there is a limit to how many manufactured objects are cached in memory).In summary, the "resolving deltas" stage involves decompressing and checksumming the entire repo database, which not surprisingly takes quite a long time. Presumably decompressing and calculating SHA1s actually takes more time than applying the delta commands.In the case of a subsequent fetch, the received pack file may contain references (as delta object bases) to other objects that the receiving git is expected to already have. In this case, the receiving git actually rewrites the received pack file to include any such referenced objects, so that any stored pack file is self-sufficient. This might be where the message "resolving deltas" originated.

gollark: UPDATE: this is wrong.

gollark: > Git uses delta encoding to store some of the objects in packfiles. However, you don't want to have to play back every single change ever on a given file in order to get the current version, so Git also has occasional snapshots of the file contents stored as well. "Resolving deltas" is the step that deals with making sure all of that stays consistent.

gollark: A lot?

gollark: probably.

External links

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.