----- Kamesh Jayachandran <kamesh@collab.net> wrote:
> Daniel Berlin wrote:
> >>
> >> Yes I got your problem.
> >> Now I have one fundamental question.
> >> I could not find the command line(svnadmin/svnlook) to modify the
> >> 'versioned proplist'(In this case 'svn:mergeinfo'), I believe
> having
> >> such a feature is not logical as it would end up user's working
> copy
> >> inconsistent with what gets committed.
> >
> > No, there is no command line tool to modify it, but that does not
> mean
> > our API does not support it.
> >
> >>
> >> So I believe the versioned property like 'svn:mergeinfo' is not
> supposed
> >> to be modified any other process than the one which creates them
> and
> >> hence no cache coherency issue.
> >>
> > This is an incorrect statement of what the API allows.
> > Whether we like this or not, it is the way it is. It does allow the
> > property to be modified by other processes.
> >
> > It is not readonly to them.
> Ok, will play with the binding once I have them.
FWIW, there have been discussions in the past where something like this would be necessary to implement a workflow where a pending commit could be made then a configuration manager could review it and finally push the transaction into the repository.
> >
> >> >
> >> Given my above explanations, I fail to see the problem over here.
> >>
> > The problem is that our API explicitly allows it.
> > Nobody is saying you are incorrect that this *isn't useful and
> logical*.
> > In fact, AFAIK, both Malcolm and I agree that it is not a useful
> feature.
> > However, regardless it *IS* a requirement that we support it until
> SVN
> > 2.0, regardless of its merit. That is the guarantee we have made
> > about our APIs.
> I fail to see how it will break the BC issue.
> My in-memory hash is just going to add one more member to fs_fs_data_t.
> As fs_fs_data_t is a private data structure changing it is not a BC issue.
> Correct me if I am wrong.
I think there have been several arguments against the in-memory hash solution, so I'm not going to touch this one. :-)
> Only think I am not sure about is it the right place to cache the info
> of this kind. Even the multi threaded scenarios where multiple
> threads(txns) sharing the same fs_fs_data_t.
I don't believe we support that currently (two threads sharing the same fs pointer).
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 14 11:22:39 2006