You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a question. Let's say I have an input file input.txt with a single number, say 3, and then have a stage that takes this input file and makes an output file output.txt with the number doubled, i.e. 6.
I can now generate a bunch of input files (say with numbers 1-10), and then regenerate the stage and output files each time.
However, if I later again plug in the original input file with 3, dud doesn't make it easy to retrieve the matching stage file (for dud checkout) or output file, even though we have processed it in the past. In other words, it's not easy to "key" the storage by the content only, but instead we must remember the "content pointer" i.e. stage file.
One could perhaps achieve content-only keying by computing dud checksum input.txt and then searching for all the past stage files for the matching input hash, which will then yield the output hash and allow us to dud checkout. However, this seems quite convoluted.
This seems to me like a common use case, so I'm a bit surprised it's not supported. But perhaps I'm wrong, or I am "holding it wrong"...
Any thoughts are appreciated. Thanks!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello, thanks again for making
dud
!I have a question. Let's say I have an input file
input.txt
with a single number, say3
, and then have a stage that takes this input file and makes an output file output.txt with the number doubled, i.e.6
.I can now generate a bunch of input files (say with numbers 1-10), and then regenerate the stage and output files each time.
However, if I later again plug in the original input file with
3
,dud
doesn't make it easy to retrieve the matching stage file (fordud checkout
) or output file, even though we have processed it in the past. In other words, it's not easy to "key" the storage by the content only, but instead we must remember the "content pointer" i.e. stage file.One could perhaps achieve content-only keying by computing
dud checksum input.txt
and then searching for all the past stage files for the matching input hash, which will then yield the output hash and allow us todud checkout
. However, this seems quite convoluted.This seems to me like a common use case, so I'm a bit surprised it's not supported. But perhaps I'm wrong, or I am "holding it wrong"...
Any thoughts are appreciated. Thanks!
Beta Was this translation helpful? Give feedback.
All reactions