Change Details

This now respects the fetch_data/store_data pattern from the loader-core. So `fetch_data` is only one iteration on one svn revision. In that call, we consume one svn revision as before and compute the contents/directories/revision. The result is stored in internal instance variable (as in pypi/debian loader for example). And `store_data`, also in the same iteration, is in charge of passing those data to the storage. If the iteration is over, we build the snapshot and stops appropriately. The internal computations did not change. Note: I'm willing to rebase all this on @anlambert's current work to improve the loading speed.

This now respects the fetch_data/store_data pattern from the loader-core. So `fetch_data` is only one iteration on one svn revision. In that call, we consume one svn revision as before and compute the contents/directories/revision. The result is stored in internal instance variable (as in pypi/debian loader for example). And `store_data`, also in the same iteration, is in charge of passing those data to the storage. If the iteration is over, we build the snapshot and stops appropriately. The internal computations did not change. Note: I'm willing to rebase all this on @anlambert's current work to improve the loading speed (D433)

This now respects the fetch_data/store_data pattern from the loader-core. So `fetch_data` is only one iteration on one svn revision. In that call, we consume one svn revision as before and compute the contents/directories/revision. The result is stored in internal instance variable (as in pypi/debian loader for example). And `store_data`, also in the same iteration, is in charge of passing those data to the storage. If the iteration is over, we build the snapshot and stops appropriately. The internal computations did not change. Note: I'm willing to rebase all this on @anlambert's current work to improve the loading speed. (D433)