[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: Philip Martin <philip_martin_at_ntlworld.com>
Date: 2001-09-18 14:52:19 CEST

Greg Stein <gstein@lyra.org> writes:

> 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

I may (usually?) want it to come back with the same name.

The merge command is all about apply deltas, and I would expect the
merge command to be able to reverse deltas and then apply them (for
removing changes made further back in the version history). Is the
deletion delta special? It certainly could be special, but does it
need to be?

Rational's ClearCase uses merge to revert deletions. Their model is a
bit different, the directory *containing* the elements is checked out
when deleting elements. Something like:

$ cleartool co .
$ cleartool rm foo.c
$ cleartool ci .

Adding new files is similar:

$ cleartool co .
$ cleartool mkelem bar.c
$ cleartool ci .
$ cleartool ci bar.c # new elements are usually created checked-out

Now if deleting foo.c produced version N of the directory, and adding
bar.c produced version N+1, I reinstate foo.c using merge (don't
remember the exact syntax, but something like)

$ cleartool co .
$ cleartool merge -to . --version main/N --reverse
$ cleartool ci .

This will produce version N+2, which contains both foo.c and
bar.c. foo.c will have the the exact same version history that it had
before it was deleted, it is the same element.

In the ClearCase model merge is the only sensible way to revert
deletions since deletion operates on the containing directory rather
than the element. Subversion may of course be different.


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.