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

Re: The unadd, undelete methods and the client README.

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-09-18 07:53:44 CEST

On Mon, Sep 17, 2001 at 03:26:48PM -0500, cmpilato@collab.net wrote:
> Mo DeJong <supermo@bayarea.net> writes:
>...
> > That certainly sounds like something revert should do. That would
> > provide the current undelete functionality but it would not give us
> > the ability to do a `snv undelete dir` on a directory delete that
> > has already been committed.
>
> Dude, that deleted dir is in revision history. Now, I don't know how
> easy/hard it would be resurrect that directory *and preserve its
> versioned history*, but simply recreating it is a one-line shell
> command (up'ing to an old version, stripping SVN/ subdirs, add
> --recursing that bad boy, and committing). And I think I just saw
> someone mail about `svn merge', which is certainly the way to go with
> this.

Merge? That doesn't make sense. You aren't merging anything... you're
getting an old revision and bringing it back somewhere in the repository.
That is the "copy" operation.

$ svn copy -r 5 foo.c restored-foo.c

That would copy revision 5 of foo.c into the current WC as restored-foo.c.
Of course, if foo.c was deleted in some later revision, you could copy back
into the WC as foo.c to restore it.

Using the copy command ensures you have the right history, too. And note
that it can call back anything, from anywhere.

> If `revert' got smarter and `unadd' and `undelete' could die, I
> wouldn't lose a wink of sleep over that change. :-)

+1 on using revert rather than unadd/undelete.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006

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.