Re: [MirageOS-devel] Irmin GC

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

>> I am not sure about the distinction between commit and commit_id. What does 
>> it mean in term of API? Do you duplicate every functionsI to take both kinds 
>> as argument?
> 
> No, you just have a single function:
> 
>    BC.Repo.commit_of_id: t -> commit_id -> commit option Lwt.t
> 
> If this returns None then the commit wasn't in the store. If it
> returns Some commit then that commit will stay in the store as long as
> you hold the commit value. Then e.g. "task_of_commit" don't need to
> return an option*, because you know the task will still be there.

I still don't fully understand your proposal I think. The `task_of_commit` 
returns an option because the current branch might be empty (and not have any 
commit). Also, a store is potentially shared by multiple Irmin instances, some 
commits might be persistent on some local stores: what is the semantics when 
you pull/push between local stores? do the "persistency" property is propagated?

> 
> * (actually, task_of_commit_id currently throws an exception if the
> commit isn't in the store, which isn't ideal)
> 
>> Also how the user decide when to create a commit or a commit_id? Persistent 
>> commit vs. non-persistent commit might make sense, but what happen if the 
>> parents of a persistent commit are not persistent: do they become 
>> persistent? Are they GC'ed as well?
> 
> You could think of a commit_id as like a weak ref to a commit.

ok, so do you propose that every time you make a commit ID persistent, all its 
parents become persistent as well? If that's the case, why not simply to (1) do 
not distinguish between commit and commit IDs (2) always consider commits as 
weak references but (3) consider them persistent when they are put in a 
reference.

so then, we you pull/push you are sharing references as well, so it is clear 
what is persistent or not. It's also fine if GC are run locally, because they 
then know both of weak references (as they are local) and persistent commits 
(just read the references).

>> I think it is important to keep the multiple-process safe if possible. Could 
>> be as simple as the GC adding a lock file somewhere (which will stop the 
>> world). If we enforce having only one Irmin process running over a local 
>> store, the invariant should be checked carefully.
> 
> I don't see how multi-process can ever work if you allow anonymous branches.

I agree. Let's add an invariant that only one instance of Irmin should run on a 
local store -- if we add this, few things in the code can be simplified (for 
instance the file locking bits in Irmin_unix) but we check that the invariant 
satisfied and fail to start a new instance otherwise.

Thomas
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel