This procedure seems like it's workable:
> svn checkout http://head-of-repository wc-dir
> svn update -r100 wc-dir/file1
> svn update -r120 wc-dir/file2
> ...etc... to get the WC based on the right revisions of all the files,
> and any additional edits needed
> svn delete http://head-of-repository
> svn copy wc-dir http://head-of-repository
It's still a little clumsy because of having to type in potentially
very long URLs in the svn copy step, but it seems like a good start.
Also, is there any way at all to force svn copy to overwrite an
existing file or directory? Though that might be there for our
protection...
Now, let me motivate why I'm trying to (ab)use svn in this manner,
instead of just using svn merge to back out changes selectively, which
people have said is the "right" way to do things.
Note that the svn book takes great pains to say that svn should be
useful for storing things other than code. So I use it to store, among
other things, various revisions of figures I'm working on for papers or
presentations. These are binary files, and so using svn merge to "back
out" one bad change while leaving the rest of the changes intact is
totally inapplicable. The only sensible way for me to back out changes
to artwork is to just revert it to a previous state! That is, the only
svn merge command that makes sense is "svn merge -rHEAD:nnn Figure1.ai"
or whatever, where nnn is the last good version. But, despite several
assertions to the contrary, a "backward patch" like this with svn merge
simply cannot back out of a file deletion. (Go ahead, try it.)
So then to back out of a deletion, you need to use the much clumsier
svn copy syntax.
Now, try (like I am) to convince other people doing art to use SVN --
it should be a godsend to them. But without a simple and coherent way
to back out file changes that doesn't involve mysterious merge
incantations and even more mysterious copy procedures, there's no
chance anyone will adopt it! The svn update command is so great for
backing out changes to files, it's a shame that there's no simple way
to say "svn commit" after those changes. Using svn delete and copy is
fine, and at least is intuitive, but it's still a lot of keystrokes
spent typing in URLs that svn should already know.
To make svn as simple for working with versioned binary files as it is
for working with code files, perhaps there ought to be some "svn
rollback" type command command that just reverts files from previous
state in such a way that svn commit then commits the changes. This
could just be a wrapper around "svn merge -rHEAD:", except that svn
merge doesn't seem to be able to deal with deleted files.
Zach
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 24 22:32:15 2005