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

Re: Useless explicit mergeinfo records

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Wed, 03 Sep 2008 10:40:46 -0400

"Mark Phippard" <markphip_at_gmail.com> writes:
> Given that you make a product that profits from SVN, then I look
> forward to seeing you more active in the mail list and to receiving
> your patches to help us make it more usable. We are always looking
> for new contributors and it would be great to have you on board.

Well, to be fair, Danil has been more and more active lately -- the
bottleneck has more been our bandwidth to review patches!

> I think this problem is going to be tough for you to solve. I do not
> know if the client has a way of checking whether it can write to a
> patch in the repos, short of actually trying to do it. You could
> argue that we ought to not allow a user to add/delete and edit files
> in this folder either. And the fact that we do is also a bug. So I
> am guessing we will need new API to ask the server this information
> and then put it in the appropriate places. Of course if each time we
> update mergeinfo we have to make a server call to see if the client
> can write to that location, then that is not going to help performance
> either. Anyway, feel free to start a new thread to discuss your
> proposals for solving this problem.

I think the real solution to this has to come with the new WC, which
will be able to do real property inheritance -- that is, if the
properties explicitly attached to path CHILD don't change, then even if
CHILD is authz-protected, we can still affect its properties by changing
the properties of one of its parents.

However, Danil (or anyone else), if you have any ideas for how to fix
this in the current 1.5 working copy or client code, please say them.


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-03 16:41:01 CEST

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.