I'm trying to figure out how it happened but cleanup has priority and
is, frankly, not going well.
I did a 'svnadmin dump ... | svndumpfilter --drop-empty --renumber-revs ...|
svnadmin load ...' creating a new repository with the last check-in
eliminated.
Now, operations on existing clones no longer work because clones have
have references to the non-existent revision '268' (the check-in that
I removed) and there doesn't seem to be a way to update the clones.
I really don't want to manually have to do the 'svn rm ...' commands on
all the .svn sub-dirs of that 268 check-in (30,000 files)
The dump/load steps I've used (and recommended in the subversion book)
are pretty useless if, by removing and renumbering revisions, all
existing clones become non-functional.
Regards
roland
Ben Collins-Sussman<sussman@collab.net> writes:
> On Dec 7, 2004, at 4:15 PM, Roland Besserer wrote:
>
> >
> > I'm in the processing of fixing an svn database because a large
> > commit was mistakenly based on an earlier, modified svn checkout
> > located in a new directory. Because it was based on an earlier
> > svn checkout, the directory tree had all the original .svn directories
> > still in place. The .svn directories were not filtered out during
> > the commit and ended up in the repository.
>
> I don't undestand, there shouldn't be any way to get '.svn' dirs into
> the repository. 'svn import' skips over them, so should 'svn commit'.
> How did you get them in there? It would be great to have a
> reproduction recipe.
>
> >
> > I'm fixing this by removing the entire check-in via the svnadmin dump,
> > svndumpfilter, svnadmin load sequence. Tedious and pretty slow.
> >
>
> You can also fix just by running 'svn rm URL' on each .svn/ URL. No
> working copy required.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Dec 8 02:07:30 2004