Hello and thanks for your reply!
As I mentioned in my original message, I understand that it is possible
to do these tasks with svn merge and svn copy. The problem is that the
syntax is a bit hard to both grok and explain (I'm trying to teach some
others how to use svn too!), and in the case of svn copy, requires
typing in long URLs seemingly unnecessarily.
And, as I noted, svn merge only for "roll backs" and svn copy only for
undelete; I've not been able to get a backward merge to work properly
when the file in question does not exist in the HEAD, and I've not been
able to get a copy to work when it would need to overwrite a file.
So again, is there any way to convince svn to commit a mixed revision
working copy as the new HEAD? Or are we really stuck with either (a)
using svn cat, which ignores history, or (b) using svn merge and svn
copy, tools which are too general for the specific problems at hand and
thus have nasty and inconsistent syntax for wholesale file reversion
and undeletion. (Note that the merge/copy syntax is great for the more
general tasks for which these tools were designed!)
If only there were some command like "svn revert" that took a file
revision number as the state to revert to! Perhaps there is?
> Or, you can take advantage of Subversions smarts and do this:
> svn copy -r100 http://server/repos/path/to/file.c ./file.c
> which will make sure that the history of your item is (mostly)
> (if you use the cat example above, it'll show up as a new item)
> Or, you can do the "merge in reverse" approach, by doing something
> svn merge -r 100:99 http://server/repos/path/to/file.c
> which merge in your "delete of file.c" *backwards* (i.e. undelete
> it). Again, I believe, preserving history. (maybe not in this case,
> one of the developers could answer that).
> Both of these use cases is documented in the Subversion book at:
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Feb 24 07:59:45 2005