dklab_realsync
dklab_realsync copied to clipboard
Is there a way to use command line switches instead of options ( config ) file?
In our setup with multiple developers we can't commit .realsync file to the repo, because it contains environment data which could be unique for every developer. We also don't want developer to answer all of those initial questions, because our setup is kind of complicated ( docker with VM on Mac or Windows where developer not always understands all the details and we want to hide some complexity ).
One option we have at the moment is to generate .realsync
file dynamically, but in my mind it would be easier to just pass command line options to the realsync
binary. Is there a way to do this or config file is the only option at the moment?
At the moment, the config file is the only option. But it supports loading of other configs:
load = some_file
So you may commit a part of the file to the repo and generate the other part only. You may also generate .realsync file somewhere in a temp directory and run
realsync path_to_this_temp_dir
I see, thanks for you advice. I was under impression that realsync
expects first attribute to be "dir to synchronize", not path to the .realsync config? It would be great if I could specify a path to the config file only with some kind of command line switch.
In normal scenario we assume developer will do git pull
of the repo, and will execute some startup script ./d start
where that d
script would pregenerate .realsync
config and will do some other "magic". If I understood correctly you recommend to create another copy of the repo just to avoid placing .realsync file into the "main" repo? But then you would have to keep "real" and "shadow" repo in sync with files changes.. Hmm..
Dmitry, why not use a "." as a "local" in .realsync?
@hempalex What do you mean by "local"?
I't a question to Dmitry about .reasync file - a "local" variable contain to absolute path to folder being synced. I'm looked in the source code and i think this question is stupid because my workflow is not the only one.
Hey gansbrest, why not include a config-sample
file in the repo, and have developers just fill in the blanks? They'd then save it as config
, and that is included in your .gitignore
.