Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
> The lock conflict scenario is the only one that really worries me.
Actually, I'd feel worried if this were on the receive-pack side, as
it is entirely valid that two or more people make uncoordinated push
into a single meeting point, but much less for something like
"fetch". I do not see a valid reason why somebody cannot avoid
fetching into the same repository in a racy way.
> But I don't think it is *so* hard to keep the current "best-effort"
> behavior.
I agree that transaction is a wrong way to look at this. I view "We
know packed refs is a lot more efficient if written once" as in the
same category as "We know we will register many new objects with
this operation, so instead of creating them into separate loose
object files, declare that the object store is 'plugged' and send
them into a single new packfile" (aka "bulk checkin"). Both are
uninterested in all-or-none execution, but merely want to declare a
boundary between a group of operations to help Git optimize them.
> I am working on a function delete_refs() for the reference API
> that deletes a bunch of references on a "best effort" basis, reporting
> per-reference errors for any deletions that fail.
I think it would make sense, but I suspect you would want to make it
clear that the function is best-effort-bulk somewhere in its name
(e.g. delete-refs-if-able or something) and make it not to
automatically fail the surrounding transaction if any. That way
an application could do things like this:
transaction-begin;
create-ref;
update-ref;
...
delete-refs-if-able;
if trying to be as atomic as possible
then
if previous delete-refs-if-able found undeletable refs
then
transaction-abort;
fi
fi
transaction-commit;
Of course, supplying delete-refs that is not best-effort separately
would make it even easier to code the above (the last if/then/fi will
become unnecessary).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html