Re: [PATCH] use lock token in non-URI form in start_put

[Tay Ray Chuan <rctay89@gmail.com>]

Hi,

On Sun, Feb 8, 2009 at 10:28 AM, Junio C Hamano <gitster@pobox.com> wrote:
> I somehow thought that the natural reading of the guarantee is *not* that
> the tokens are unique over the lifetime of the server installation (iow, a
> lock token you obtained today will never be used in the future, and it is
> a token that the server never has used before), but it merely guarantees
> that there are no any two outstanding locks that share the same URI, lest
> one client's unlock request breaks the wrong lock.  But I may be wrong here.
>
> ...
>
> What breaks and how, if we do not even use a random string but a fixed
> suffix ".temp" here?  I am not suggesting we actually do that, but I'd
> like to see how important the uniqueness is here to better understand the
> issue.

Having a temporary file dually ensures 1) no repository corruption 2)
no pushing simultaneously to a object file. I think an example of a
racy situation would help illustrate why a unique temporary file is
needed (pun not intended).

Imagine if two git clients, A and B, are trying to push to the
repository at the same time. Let's assume that A is our "official"
implementation of http-push, while B is a rogue, forked implementation
of A. B is rogue because, unlike A, it doesn't care about locks on
info/refs, refs/head/<branch>, etc. -- stuff that A checks for before
beginning pushing objects. But apart from that, A and B are similar in
all other aspects.

It so happens that they're pushing the same object, say, X, to the
same repository. A starts first, and during the period of the transfer
of object X, B starts too.

If we had used the ".temp" as you had suggested, we would have some
problems due to unexpected behaviour as a result of A's and B's
simultaneous writing to the file X.temp.

If we had used the token instead for the temporary file name, the
chances of this occurring is lowered, but still possible. That's
because we're using a token from a lock somewhat arbitrarily. For
example, if A was pushing to the branch "branch_A", it would lock
refs/heads/branch_A and use that lock token, and if B was pushing to
"branch_B", it would use the lock token obtained from locking
refs/heads/branch_B.

Going back to your first point on the uniqueness of the lock token,
one only needs a token that's unique for the locks currently in
effect. If the server had given us a token that had been used before,
but isn't used by anyone else *now*, then it's ok, since we wouldn't
be overwriting anybody else's file.

Thus, a token that's unique *now* is sufficient.

-- 
Cheers,
Ray Chuan