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

Re: [PATCH] Prevent the modification of the URL [was 1.0.1 veto for r8959]

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2004-03-22 21:37:08 CET

Ben Collins-Sussman <sussman@collab.net> writes:

> Greg Hudson wrote:
>
> > > Perhaps it would be better if the switch editor
> > > modified the directory URL at close_directory time ("I have made the
> > > necessary changes to this dir to change its location" vs. "I plan to
> > > make the changes to this dir to change its location").
>
> I don't agree... the whole design of the update-editor is based on the
> idea that open_root() and open_dir() immediately write out the new
> (revnum, URL) into the entries file with the 'incomplete' flag. This is
> the reason checkouts/updates are restartable.
>
> So the real issue here is: who's in charge of validating the URL before
> the editor-driver actually begins to drive?
>
> I think the spirit of makl's patch is just fine: the reporter code can
> definitely do some sanity checking before beginning the editor drive.
> The "old" txn-based reporter code used to do that, so makl's patch fixes
> a regression of some sort.
>
> But in addition to makl's patch, I think we should also try to identify
> earlier opportunities to validate the URL as well.

+1.

It's silly for the server (who actually has a chance in the world of
knowing that a given path doesn't exist in the repository) to tell the
client anything about that URL other than, "It doesn't exist". And
open_root() is, in a sense, a form of confirmation that the parameters
of the switch/update/checkout were at least valid.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 22 21:38:51 2004

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.