How do I restore these deleted tags?

I need to restore some deleted tags and I'm not sure how to do it. We
have a single repository served through Apache2 hosted on Gentoo
Linux. Clients are mixed, but I'm trying to do this on the command
line on a Mac. Client and server are Subversion 1.2.3. Here's the
setup [1]:

* We had a project foo.example.com in the repository. In revisions
between 2704 and 3075 a variety of tags of this were created:

https://www.example.com/repo/foo.example.com/tags/release-1.0-2704
https://www.example.com/repo/foo.example.com/tags/release-1.0-2761
[...]
https://www.example.com/repo/foo.example.com/tags/release-1.0-3075

* In revision 4129 we realized that though the tags had "1.0" in the
name, they were actually for version 2.0 of the project, so we wanted
to rename the tags like this:

https://www.example.com/repo/foo.example.com/tags/release-2.0-2704
https://www.example.com/repo/foo.example.com/tags/release-2.0-2761
[...]
https://www.example.com/repo/foo.example.com/tags/release-2.0-3075

We also renamed the 1.0 branch to 2.0. I wasn't at the keyboard, so I
can't tell you what, but something went wrong and half the tags ended
up empty. I don't care how it happened, but now that it did, we need
to deal with it. We didn't realize the problem at the time, though.

* In revision 4652 we decided that the project directory in the
repository shouldn't be called foo.example.com but instead foo-
project, so we renamed the entire project directory, so now we have:

https://www.example.com/repo/foo-project/

* In revision 4756 (that's today) we finally noticed the problem with
the empty tags, and I tried to fix it. I started by checking out the
entire foo-project—trunk, branches, tags and all. It's a small
project, so this wasn't a problem. I then deleted the tags which were
empty and committed this.

Now I wanted to copy the tags back into the working copy from the
point where they were created in the past. I thought I would go into
the tags directory in my working copy and use peg revisions to copy
the old tags, like this:

$ svn ls -r4128 \
https://www.example.com/repo/foo.example.com/tags/release-1.0-2704@4128
bar/
baz/
$ svn cp -r4128 \
https://www.example.com/repo/foo.example.com/tags/
release-1.0-2704@4128 \
release-2.0-2704
svn: Path 'https://www.example.com/repo/foo.example.com/tags/
release-1.0-2704@4128' not found in revision 4128

The list command works, but the copy command fails. Turns out peg
revisions don't work with the copy command yet because it hasn't been
implemented:

http://svn.haxx.se/dev/archive-2005-11/0001.shtml

Daniel said he could implement it, but checking the commit messages
on trunk it doesn't look like he has yet, which is understandable
since it was just discovered a few short weeks ago.

Starting over, I then tried checking out a working copy of all the
tags before the erroneous rename, and copied the tags to their new
names:

$ svn co -r 4128 \
https://www.example.com/repo/foo.example.com/tags@4128 \
foo-tags
$ cd foo-tags
$ svn cp release-1.0-2704 release-2.0-2704
$ svn cp release-1.0-2761 release-2.0-2761
[...]
$ svn cp release-1.0-3075 release-2.0-3075

If I now try to check in, that fails:

$ svn ci
svn: Commit failed (details follow):
svn: PROPFIND request failed on '/repo/foo.example.com/tags'
svn: '/repo/foo.example.com/tags' path not found

That's more or less expected. Neither can I update:

$ svn up
svn: REPORT request failed on '/repo/!svn/vcc/default'
svn: Cannot replace a directory from within

I suppose that's more or less expected too. So I switch to the new
URL. The switch works—the 1.0 tags get deleted, more 2.0 tags get
added (those which were not broken and which I did not delete in
revision 4756), the later 3.0 and 3.1 tags get added—but the commit
still fails:

$ svn switch \
https://www.example.com/repo/foo-project/tags
[lots of output]
$ svn ci -m ""
Adding release-2.0-2704
Adding release-2.0-2704/bar
svn: Commit failed (details follow):
svn: COPY of release-2.0-2704/bar: 404 Not Found (https://
www.example.com)

"bar" is one of the directories that are supposed to be in each tag,
but which were absent in the improper copy performed in revision
4129. So there are several things I don't understand about this now:

* If Subversion is trying to create the new release-2.0-2704 from the
old release-1.0-2704 at revision 4128, why can't it find the bar
directory which does exist there?
* If Subversion is trying to create the new release-2.0-2704 from the
failed release-2.0-2704 directory with no contents, then why can it
find the release-2.0-2704 directory at all, since it was deleted in
revision 4756?

Since my mail client would be sure to mess up the Apache log of this
commit attempt if I pasted it in here, I'll attach it as foo.log.

Status seems to have reasonable things to say:

$ svn st release-2.0-2704
Path: release-2.0-2704
URL: https://www.example.com/repo/foo-project/tags/release-2.0-2704
Repository UUID: 38b864bf-3aee-0310-89d1-a2d1cfbe3d77
Revision: 4128
Node Kind: directory
Schedule: add
Copied From URL: https://www.example.com/repo/foo.example.com/tags/
release-1.0-2704
Copied From Rev: 4128

Now that I've tried and written about all that, it occurs to me that
I can probably just recreate the tags very simply, like this:

$ cd tags
$ svn cp -r2704 \
https://www.example.com/repo/foo-project/branches/2.0 \
release-2.0-2704
$ svn cp -r2761 \
https://www.example.com/repo/foo-project/branches/2.0 \
release-2.0-2761
[...]
$ svn cp -r3075 \
https://www.example.com/repo/foo-project/branches/2.0 \
release-2.0-3075
$ svn ci -m ""

But now that I've written it all down, I may as well ask first
whether that seems to everyone to be the best way to proceed, or if
someone has another suggestion. And perhaps someone who knows can
look at all the above behavior and see if all of it seems right.
Perhaps there's a bug lurking in there somewhere.

[1] Pardon my URL anonymization; I hope I haven't introduced any
typos or nonsense as a result.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org