On 01/05/2012 07:44 AM, Johan Corveleyn wrote:
On Wed, Jan 4, 2012 at 7:42 PM, Julian Foad<julianf...@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".
--
Mark Mielke<m...@mielke.cc>
