create 'Repository' enum and move Index enum downwards

[danieleades]

this is a first draft of the changes we discussed regarding moving the enum in the index 'downwards'.

Since the file management is shared between the two index strategies, it's really only the repository management which is configurable, so this is isolated as an enum (rather than the entire index).

This is a work in progress, but ready for initial review

[codecov]

Codecov Report

Merging #50 into master will increase coverage by 0.15%.
The diff coverage is 3.70%.

@@            Coverage Diff            @@
##           master     #50      +/-   ##
=========================================
+ Coverage    0.00%   0.15%   +0.15%     
=========================================
  Files          50      48       -2     
  Lines        1988    1918      -70     
=========================================
+ Hits            0       3       +3     
+ Misses       1988    1915      -73     

Impacted Files	Coverage Δ
src/config/mod.rs	0.00% <0.00%> (ø)
src/index/repository/cli.rs	0.00% <0.00%> (ø)
src/index/repository/git2.rs	0.00% <0.00%> (ø)
src/index/repository/mod.rs	0.00% <0.00%> (ø)
src/index/tree.rs	0.00% <ø> (ø)
src/index/mod.rs	9.09% <13.63%> (+9.09%)	⬆️
src/db/schema.rs	0.00% <0.00%> (ø)
src/api/owners.rs	0.00% <0.00%> (ø)
src/api/publish.rs	0.00% <0.00%> (ø)
src/api/download.rs	0.00% <0.00%> (ø)
... and 12 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ff26cc3...769dc58. Read the comment docs.

[danieleades]

• i've created a new trait Repo. it's private to the repository module, and purely for convenience. Having said that, it creates the possibility of exposing that trait, and using a trait object in the index, rather than an enum. This would allow consumers of your crate to use the index with any type that implements Repo (without extending the enum).
• you've got a lot of 'unwraps' in the git2 repository. I'm assuming the mutex is only there to make the index Sync so you can use it as a state object in the tide server? I would consider moving the mutex upwards into the calling code, because it's not clear why it's needed in the index. (that's a job for a different pull request)
• i've moved the index config into the index module, but i'm totally open for discussion about that.
• i've used a couple of 2018-edition imports. i can change those to 2015 imports to be consistent with the rest of the repo.
• missing a lot of documentation
• this diff removes ~120 lines of code!

[Hirevo]

Sorry for the wait.
I am on board with the idea and I find the implementation here rather convincing, I don't have many remarks to make.
Don't worry about the 2018-style of imports, I've done the same in some places as well (like in src/logs.rs).
I am also on board with moving the index-related config to the index module, it is also what I did in #46 where I moved the index config in the alexandrie-index crate.

One funny thing, though, is that there are many different types named either Repo or Repository now:

• alexandrie::index::repository::{Repo, Repository}
• alexandrie::index::repository::git2::Repository
• alexandrie::index::repository::cli::Repository
• alexandrie::db::Repo<T>
• git2::Repository (the one from the external git2 crate)

And the worse thing is that I don't even know how to rename most of these things.
I guess we could rename crate::db::Repo<T> to crate::db::Database<T>, at least this would isolate Repository as an Index-related term within Alexandrie.
I guess that naming is, indeed, rather hard in computer science.

[danieleades]

One funny thing, though, is that there are many different types named either Repo or Repository now:

• alexandrie::index::repository::{Repo, Repository}
• alexandrie::index::repository::git2::Repository
• alexandrie::index::repository::cli::Repository
• alexandrie::db::Repo<T>
• git2::Repository (the one from the external git2 crate)

And the worse thing is that I don't even know how to rename most of these things.
I guess we could rename crate::db::Repo<T> to crate::db::Database<T>, at least this would isolate Repository as an Index-related term within Alexandrie.
I guess that naming is, indeed, rather hard in computer science.

Indeed it is rather hard!

The idiom i use is that a name should be the most logical and descriptive name it can be local to the containing module. Then, when referring to those types from other modules you can either use the qualified name, or rename the import as required. By that measure git2::Repository and cli::Repository are completely unambiguous. Personally, I think this is far more preferable than having paths like repository::git::GitRepository (which is pretty redundant). This is fine for private types, but it gets harder if you name your public types this way, and you want to re-export them all from the root of your crate...
Also having object names clash with trait names is pretty confusing.

I totally agree with you that the current names i've got here are not quite right though.

[danieleades]

i'm re-worked the names slightly, mainly by making sure each instance of Repository is unambiguous within its containing scope. It's not an ideal situation, but personally, i believe this is less confusing than having multiple synonyms of 'Repository' throughout the codebase.

There's another option here, in this diff the only purpose that the Repository trait has is to add dynamic dispatch to the enum. This reduces boilerplate, by avoiding matching the enum variants in every method. For the cost of a little extra boilerplate, this trait can be removed entirely.