On Wed, Sep 3, 2008 at 5:08 AM, Danil Shopyrin <danil_at_visualsvn.com> wrote:
>> How could merge tracking be merge tracking if it does not do this? It
>> has to scan the working copy to find out if you have any subtree
>> mergeinfo.
>
> I don't agree. The authz-blocked path isn't somehow touched in the
> merging branch and it's surprising behavior when the user-visible
> properties of the file are changed. And it's unacceptable that commit
> is blocked because of this.
As I said to Karl, I was not responding to this part of the thread (I
forgot about it). I was talking about the performance hit of crawling
the WC, and just saying there is no way to avoid that.
>> I do not think it makes sense to try and change this. If we really
>> implement a new WC, this checking will become trivial as it will no
>> longer be crawling the WC to find this information. That seems like a
>> better solution given that the code is working as intended.
>
> From my point of view, the whole Subversion usability is seriously
> damaged since merge tracking was released in 1.5. I work with
> Subversion for several years and I was really disappointed by released
> behavior (and most of my friends too). Looks like a big broken window.
>
> That's why I think it's a good job to make merge tracking better in 1.5.x.
>
> --
> With best regards,
> Danil Shopyrin
> VisualSVN Team
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.
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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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:18:25 CEST