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

Re: svn commit: rev 5814 - in trunk/subversion: libsvn_wc tests/clients/cmdline

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-05-06 12:42:33 CEST

cmpilato@collab.net writes:

> Philip Martin <philip@codematters.co.uk> writes:
>
> > I still think the correct approach is to make the repository send the
> > delete for the missing subdirectory.
[...]
> And I still disagree with you.
[...]
> Now, part of my disgust with your insistance on making the repository
> do this work is that I assumed (as did Brian Denny) that this change
> would require modifications to svn_repos_dir_delta(). Those
> modifications (at least the theory behind what Brian started doing
> there) were completely I'm-gonna-minus-one-all-over-your-head wrong
> in nature.

I didn't look at Brian's repos code in detail, so I can't comment on
that, my question is about svn_ra_reporter_t.delete_path. This is the
function that the client calls to describe a working copy path as
missing. Obviously the client must know about the path to be able to
call delete_path, it strikes me as odd that in this case the client
doesn't get any response from the repository. In the normal case (no
repository delete) the repository responds to the delete_path call,
why should the delete case be different? It's possible I don't
understand the intention behind delete_path.

> However, it occurs to me that perhaps the repos layer could provider a
> second editor which is composed with the dir-delta editor, and whose
> close_dir() function would perform the necessary checks and transmit
> the extra editor->delete_entry() calls.

Interesting idea.

> I dunno how that it would all turn out. I still think the fix should
> be client side.

I agree it could be solved there, but solving it on the client side
means that every client has to be aware of the problem and has to find
a solution.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 6 12:43:24 2003

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.