2008/7/21 Karl Fogel <kfogel_at_red-bean.com>:
> "Chia-liang Kao" <clkao_at_clkao.org> writes:
>> This is mainly cleanup. token uniqueness are mentioned in fs_fs layer
>> lock unction as TODO:
>>
>> /* If the caller provided a TOKEN, we *really* need to see
>> if a lock already exists with that token, and if so, verify that
>> the lock's path matches PATH. Otherwise we run the risk of
>> breaking the 1-to-1 mapping of lock tokens to locked paths. */
>> /* ### TODO: actually do this check. This is tough, because the
>> schema doesn't supply a lookup-by-token mechanism. */
>>
>> I think it's a bit overkilling for this feature to implement the check
>> that is currently lacking underlying facilities. I am also wondering
>> why do we need to lock-token to be globally unique? not just unique
>> per-path? Given the comment stating we don't do any lookup-by-token,
>> I don't suppose lock would work across renamed nodes either? Or am i
>> being naïve and missing something obvious here?
>
> The reason the current code does not check ("guard") to make sure the
> token is unique is that the current code generates those tokens itself,
> and so it knows they're unique. If external code becomes responsible
> for generating tokens, then that guarantee goes away.
Well from what i can see in the code is that fs layer API actually takes
the token optionally, which might not be generated by us. It's just that
no one is using that API.
> The requirement that the tokens be unique is not for Subversion, it's
> for Subversion's consumers -- the whole point of a lock token is to
> unambiguously, universally, uniquely identify the lock. (I can't think
> of any more words beginning with "u" to help make the point. :-) ) It's
> not Subversion that needs that guarantee -- it's other software that
> might be helping users communicate, and that might depend on unique lock
> tokens to do so.
The feature I am asking and implementing is not about adding non-unique
locks, if you read my original patch. it could be a side-effect if
the feature is
not used carefully, which is the same thing if the current fs layer api is not
used carefully.
> Can you describe why you want this feature? It might help us all think
> better...
This is for locking through a slave repository with pushmi, we'd use the
pre-lock hook to lock the mater server and then notify svn about the token
we got from the master, so they are in sync.
Cheers,
CLK
Received on 2008-07-21 23:09:02 CEST