2012–13 National League B season

The 201213 National League B season was played from September 14, 2012 to February 10, 2013. The regular season was won by HC Ajoie with 105 points.

2012–13 National League B season
LeagueNational League B
SportIce hockey
DurationSeptember 14, 2012 -
February 10, 2013
Number of games50
Number of teams11
Regular Season
Season ChampionsHC Ajoie
Top scorerMarco Truttmann
(EHC Olten), James Desmarais
(HC Ajoie)
Playoffs
Swiss champion NLB
ChampionsLausanne HC
  Runners-upEHC Olten

Participating Teams

Regular Season Standings

Team GP Pts W L OTW OTL SHW SHL
1. HC Ajoie 5010531121141
2. SC Langenthal 5010329113133
3. EHC Olten 5010232140022
4. Lausanne HC 509831161011
5. EHC Visp 508523172143
6. Chx-de-Fds 508323172125
7. GCK Lions 507022240202
8. HC Red Ice 506918210443
9. EHC Basel Sharks 506418262121
10. HC Thurgau 50266380123
11. HC Sierre-Anniviers 50205421011

Playoffs

  Quarter-Finals Semi-Finals Finals
                           
  1 HC Ajoie 4  
8 HC Red Ice 2  
  1 HC Ajoie 2  
  4 Lausanne HC 4  
2 SC Langenthal 4
  7 GCK Lions 0  
(Pairings are re-seeded after the first round)   4 Lausanne HC 4
  3 EHC Olten 0
  3 EHC Olten 4  
6 Chx-de-Fds 3  
  2 SC Langenthal 2
  3 EHC Olten 4  
4 Lausanne HC 4
  5 EHC Visp 1  

League Qualification

Lausanne HC will play the losing team of a Play-Out tournament from the National League A for the 12th and final spot in the top division next year.

gollark: Or Great Information Transfer.
gollark: Git stands for GIT Is Tremendous.
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.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.