Generating generations of files
PythonList at DancesWithMice.info
Mon Apr 29 19:53:07 EDT 2019
On 30/04/19 8:04 AM, Chris Angelico wrote:
> On Tue, Apr 30, 2019 at 6:00 AM DL Neil <PythonList at danceswithmice.info> wrote:
>> Are you aware of a library/utility which will generate and maintain the
>> file names of multiple generations of a file?
> Commit it to a git repository. All the generations have the same name,
> but you can compare them, explore past versions, etc, etc, etc, with a
> rich set of tools. And it's easy to invoke git from a program (if you
> need information from stdout, most git commands accept a "--porcelain"
> parameter), so you can fully automate.
(and all 'the work' is already done)
I've seen various Py + GIT entries in the library, so can I assume the
ability to output a file directly into a GIT repo/branch, instead of the
Is this a common use-case?
Three immediate thoughts:
1 I'd have to put GIT onto one of the users' storage servers (see
comment elsewhere about re-thinking location of file-storage). OK, so
I'm lazy - but I work hard at it!
2 We'd need a user-friendly GIT-client for the users. The words "Linus"
and "user friendly" don't often sit together happily in the same
sentence (and if he ever reads this...)
3 The users' case for retaining older-versions is so that they can
compare between runs. (I blame myself, showing them filecmp, noting that
they could quickly employ Calc/Excel...)
Easiest explained example = some slight change in a variable results in
a 'surprise' result. (which scenario is almost identical to the
'sensation' when a user throws some data at *our code* and finds some
'error' - schadenfreude means there's always a silver lining!)
Earlier, I had suggested dropping the o/p of each 'run' into its own
sub-dir of the client-/experiment-directory (perhaps using date-time)
and thereby completely avoiding any fileNM 'collisions'. Lead balloon!
Thanks! I'll have some little git - apologies, I mean: "a Git expert",
More information about the Python-list