[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [merge-tracking]Why we need PATH_TXN_MERGEINFO in merge-tracking?

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2006-09-14 09:37:00 CEST

>
> 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.

> >
> 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.
Having to serialize merge tracking info to disk in transactions is the
price we pay for this guarantee.

This is why both Malcolm and I believe this guarantee should be
removed in SVN 2.0. But we cannot remove it in SVN 1.5.
--Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 14 09:37:18 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.