On 18/04/14 18:02, Izack Varsanno wrote:
Hi!
> Pascal, you are right regarding presets that just been change.
> Problem is we don't have any way to know which is the "new" one.
> I might write another script which will list all presets and will let
> you choose which one to copy over.
>
> But the way I work with presets, I just create a new one if needed and
> never change one that already work.
It might be worthwhile to consider instead of moving presets between the
DBs to dump them to intermediary files and just copy from those files to
both DBs. Simply just as you can use your favourite unix tools to manage
file diffs. (The intermediary file could probably be the result of the
export within dt.)
E.g. I'd find it quite clever to have presets in files instead of the db
as I'd be able to git them. (Your usecase is IMHO pretty general and
shows that it would be helpful to have presets not in the DB at all.) In
your workflow it could almost work that way... You could add something
like git pull->update DB[i]. If you touch your files with the DB date it
could be "good enough" to always propgate the right version to the git.
Just a tought.
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Darktable-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/darktable-users
