Continuing the discussion from About Duplicacy nomenclature:
Now that we have -repository for init and add, could we remove -pref-dir?
Since repository doesn’t leave any weird files in the repository, i think it offers a much better use-case and does the same thing -pref-dir would do, only better.
What’s your opinion on this?
I agree. I can’t think of any use case to keep -pref-dir.
Agreed. The repository turned out to be a better implementation of the same idea.
Besides, I think putting things into the preferences file is a better way to go about doing more complex stuff like settings bandwidth limits, prune retention policies etc… 
Being a new user I kept wondering what -pref-dir could do for me. I decided to ignore it.
I guess we can just remove it from the documentation here and @gchen can remove it from the init and add commands?
I don’t know if we should remove -pref-dir. It should be deprecated for sure, but removing it would cause some backward compatibility issue if people are still using it.
I have 30 million files being backed up - pref-dir is one thing I used to split them into 50 different backup jobs. I used -pref-dir to keep the repositories clean and in logcial area(s) per backup job.
My command line .bat files which are run from a task scheduler pass that parameter I believe. How would this change?
Thanks,
–J
Nothing is changing AFAICT; the idea now is just to deprecate -pref-dir in favour of -repository which TBH, is a much cleaner solution.
In your case, you still have a .duplicacy file in the root of each repository pointing to the actual location of a .duplicacy preferences directory. This isn’t as clean as it could be.
With the -repository setting, instead of referencing the location of the preferences, the preferences file references the location of the repository. And you’d cd to the .duplicacy directory instead of the repository. But you’d have no superfluous .duplicacy file or folder anywhere inside the repository.