"Chia-liang Kao" <clkao_at_clkao.org> writes:
> 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.
Ah, I didn't realize that.
>> 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.
Yes, I understand that non-unique locks is not your goal; custom
lock-tokens is.
>> 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.
In other words, the slave would be locked too, and it would be using the
exact same lock token as the master?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-21 23:15:49 CEST