On Mon, Feb 17, 2014 at 8:48 PM, Baruch Burstein <bmburst...@gmail.com>wrote:
> 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?
>
Indeed! The interaction part is, but collecting a version's checkout data
is a relatively messy thing for clients to have to deal with. i have a set
of callbacks in place which allow a generic "yes/always/no/cancel"
mechanism which some types of applications can use to offer feedback. If
the callback is NULL, assume "always" and overwrite everything. So the
client doesn't have to provide one. Extracting the data is not all that
hard, it just requires some deal of knowledge of how fossil works. A
checkout-like operation can (with one minor currently missing detail) be
implemented using only public APIs.
> 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?
>
The new repo-extract functionality does exactly that, but i want to provide
a shell or GUI client the option to offer the user a choice of operations
when an extract would overwrite anything (eventually with undo support -
that's not been ported yet). Ideally they pass a simple callback to the
checkout func. The callback will get the name of the file and a flag will
tell the user what's happening:
- extracting a new file
- about to replace this file (prompt if needed)
that can be used to provide a status report of what's going on (it can take
a while) and give the user a chance to cancel it by returning non-0 from
the iteration callback.
A client which wants more control over the process could implement a loop
similar to this one:
http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/artifact/cb2e81023e24b675?ln=1166-1215
That can all be done using the public API.
:)
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
