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

Re: Issue #1075 analysis

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-04-21 19:24:53 CEST

Brian Denny <brian@briandenny.net> writes:

> On Sun, Apr 20, 2003 at 10:44:02PM +0100, Philip Martin wrote:
> > Brian Denny <brian@briandenny.net> writes:
> >
> > > (1) I *think* that the editor could "do the right thing" by
> > > always generating a delta when the source directory is missing --
> > > i.e., if the directory is present in the target, do an
> > > add (restore), and if it's absent in the target, do a delete. But
> > > that would also require some way of signaling a missing path to the
> > > reporter as distinct from a deleted path (not to mention that i have
> > > no idea how the missing item should be represented in the transaction
> > > "source tree").
> >
> > 'svn update' will replace missing directories, even if nothing has
> > changed in the repository. Can that mechanism be used to cause the
> > delete to get sent?
> i don't understand what you have in mind -- are you saying that we
> should restore the missing directory first, so that when we do the real
> update, we get the correct delta?

If I 'rm -rf' a directory that is part of a working copy directory,
and then do 'svn up', the missing directory gets replaced. It would
appear that the client is describing the missing directory to the
repository, and the repository is sending an update to reinstate it.
That appears to be something like what you have dscribed in (1) above,
and so I would have thought it was possible to get the repository to
send a delete, in the same way it sends an update. (Note, I haven't
examined the code, so I'm not claiming this will definitely work, just
that I think it might work.)

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 21 19:25:40 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.