On 04/22/2014 10:41 PM, Izack Varsanno wrote:
Hi!
> I can add the option to update existing record, assuming you sure that
> you want the src_library.db to override the dest_library.db presets
> (For me, it won't work because I can create new presets on my desktop or
> laptop, so in the sync script, I can't automatically decide which one to
> override)
I wonder about this. If I understand it you have two sources. DB1 which
has presets in dir1/ and DB2 which has presets in dir2/. Now currently
you sync manually from DB1 to DB2 or vice versa, depending on what has
the current preset.
Now, what I considered is, that you might only work on one of the DBs at
a time. If I understood correctly, one is the laptop one your
workstation so you use e.g. DB1 on the road and DB2 at home. If you
ensure, that every DB reads presets from the file as soon as it is opend
and dumps out all presets as at closing of the DB, then the last DB you
worked at will have the current presets, right?
I see your point, but it arises only if you are working on both DBs
simultaneously.
However, even then if you add some version controlish thingy (git in my
example, could be eveything else like rcs,cvs,svn,hg,<whathaveyou>) on
top of your source dir, git should complain about a clash if it exists
and let you resolve it manually if needs be or if no clash exits just
happily commit/push/pull/merge stuff and keep track of the changes.
So a dt startup script could be something like
$ cd $HOME/.config/darktable
$ if (hasnetwork); do git pull ; done
$ /opt/photo/bin/darktable
$ git commit -m "Changes on DB1"
$ if (hasnetwork); do git push ; done
With a centralized git origin for the push.
> Adding override option needs just few simple changes on the script.
> But again, it assume that you know where is the source and where is the
> target.
> (with the current script, you can first append from "db#1" to "db#2" and
> then append from "db#2" to "db#1" - which will append all new presets to
> all databases)
I understand this is necessary if you to for the DB right away as the DB
does not allow you to use something like git.
>>>> 3. It is reasonable that one of the next DT releases will
>>>> separate presets from pictures management.
>>> IMHO this would be the best way to go and avoid the
>>> necessity to do anything else.
>> Agreed. Is this being seriously considered or discussed at all? It might be
>> good to start there, before putting too much effort into anything external.
>> If for some reason this change isn't going to be considered, though, the
>> external tools will be very useful and welcome. Thanks for your work on
>> this. :)
> I really hope that one of the Darktable developers will give us more
> insights on this...
There was some discussion about it in the past but I don't think there
was some final decision yet. There're IMHO very good reasons to move
presets, styles, vocabulary (tags if you want) sources outside of the
image management db as soon as not searching is involved.
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Darktable-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/darktable-users
