On 30/04/19 8:04 AM, Chris Angelico wrote:
On Tue, Apr 30, 2019 at 6:00 AM DL Neil <pythonl...@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.
Great idea!
(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
file-system?
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!
Sigh...
Thanks! I'll have some little git - apologies, I mean: "a Git expert",
research further...
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
