On Fri, Feb 14, 2014 at 10:55 PM, Stephan Beal <sgb...@googlemail.com>wrote:
> That will be the basis of the up-coming checkout support, but solving
> checkouts at the library level first requires figuring out how to allow for
> user-level interaction ("overwrite file? Yes/All/No/Cancel?") for each file
> (like fossil does) while still hiding the gory fetching/looping details
> from the application. A prototype is in place, but is as yet untested.
>
Why does the library need to do any user-level interaction? Isn't that is
the job of the application? The library sends the file path/contents to the
application, and let the application do whatever it wants with it. If the
application decides that what it wants is to save it to disk and there is
already a file by that name, it is it's responsibility to do some form of
user-interaction to figure out how to handle this, no?
--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
