When would you use mergesort over quicksort and
  vise-versa?

QuickSort abuses the stack as it is a recursive algorithm
(sure one can write a non recursive version using the heap instead)
Typically for each recursion it uses
  [Ret Addr] [pItem1] [pItem2] ie: 16 bytes

The problem is that it eats memory, so it is inevitably finite in its capacity.

MergeSort is dividing the data down into buffers and then merging
them. It is simply repeatedly subdividing the data and merging it.
Also not an 'inplace' sort.
One needs a recipient buffer the same size as the original data for the 'merge'
(or with tweaking, half the size - further tweaking reduces it but ...)

I have long preferred the Shell Sort algorithm, which is totally 'inplace'
(Also sometimes called the Comb Sort)

The academic anser is going to be : use MergeSort when the remaining
stack divided by 16 is less than the number of keys.

The real world answer is sort stuff on disk in blocks and recursively
merge them if it is anything above a trivial amount of data (eg: a few
hundred Kb) and use ShellSort for the block sorting.
Speed matters, but an out of stack space or heap space gives a zero speed.