On Jul 10, 2007, at 17:04, Jason Winnebeck wrote:
> If I dump and reload a corrected repository on the server, how do I
> get
> my clients to work again?
>
> Based on my work from "svn mv "breaks" annotate" thread, I have
> corrected the converter's problems. This resulted in a dumpfile with a
> few less transactions. However, the old repository was live. What I
> did
> was did the corrections in a separate repository, then did an svnadmin
> dump --incremental of the changesets since the conversion. The
> resulting
> repository seems to be how I want it with the proper history
> intact, and
> I set the svn:date props of the revisions to be in the proper time, so
> everything looks right. Problem is that the revision numbers are
> different.
>
> Now, the clients can't operate on the repository. I am not surprised:
>
> svn: REPORT request failed on '/svn/AHM/!svn/vcc/default'
> svn: No such revision 11275
>
> Trying to do a "switch" or a "co" over the old location doesn't
> seem to
> help, either. They give the same error. What can I do to replace an
> existing repository? It's only been live for a couple of days and
> we are
> a small team so the subtleties are OK (i.e. we are all at HEAD and
> don't
> have anything referring to specific numbers yet, but might have some
> changed files).
>
> Is the only solution to manually "pack out" changes, delete everything
> and start over?
Not sure what you mean by "pack out", but yes, it sounds like your
new repository with the fixed conversion is a different repository
than the old one with the broken conversion. Assuming nobody has
committed anything to the old repository, you should delete the old
repository, make the new one live, and everyone should trash their
working copies and check out new ones.
To make the new repository, you may even want to "svnadmin create"
and then "svn load --ignore-uuid". This way, the new repository will
get a different unique ID, which would be correct, since the new and
old repositories are different. This way, people will be forced to
get new working copies. If you don't change the UUID, somebody might
forget to get a new working copy, and might commit changes from it,
which will almost certainly not work and will cause you problems
later that you'll have to track down.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 11 00:36:04 2007