On 01/05/2012 07:44 AM, Johan Corveleyn wrote:
> On Wed, Jan 4, 2012 at 7:42 PM, Julian Foad<julianfoad_at_btopenworld.com> wrote:
> [ ... ]
>> SERVER DESIGN
>> Any time the server is about to send a set of revision properties to
>> the client, the server looks up the extended author fields and adds
>> corresponding properties to the set of revision properties that it
>> reports to the client. These property values override any values The server looks up the extended author fieldsthrough some mechanism not defined here,using the value of the"svn:author" property as a key. The server may cache the results, provided that there is a way for the administrator to make the server use updated information.
> Just wondering: a lookup approach, does that address the original
> problem that started this whole discussion? I.e.: how to avoid the
> information loss when importing from GIT into a Subversion repository?
> Since GIT has those additional attributes (display name and email
> address?) annotated with every commit, a lookup approach is in general
> not sufficient to store this information ...
> Not important I think, but I'm just noting the discrepancy ...
I was thinking this as well, but I dismissed it (perhaps prematurely)
with the thought that GIT being DVCS, does not have the capability to
have a centralized authority in terms of mapping these attributes.
Subversion is designed for centralization of the metadata, and therefore
it may be a better fit for the mappings to also be centralized. Somebody
who is importing GIT to Subversion might choose to do so by selecting an
appropriate unique identifier for their requirements they could then
import the mappings to the centralized record mapping unique identifier
to attributes. LDAP or what have you.
Alternatively, the model could normally prevent svn:author:* to be set
but if they happen to exist, they could be served as historical data.
Either way could be made to work. Not sure what is "best".
Received on 2012-01-05 18:18:16 CET