James,
If you try to make your includes/excludes more specific you can speedup
your test cycle using svndumptool.py:
svndumptool.py check --check-actions dumpfilename
That check is much faster than svnadmin load and shows what would go wrong
when you try a load.
The homepage of svndumptool is
http://queen.borg.ch/subversion/svndumptool/
Martin
On Wed, 24 Aug 2005 jamesl@appliedminds.com wrote:
> Karl-
>
> On Wed Aug 24 19:13 , kfogel@collab.net sent:
>
> >James, you've got copies in your tree. Some of those copies have
> >sources that are either
> >
> > - in revision trees from before the earliest revision in your
> > dumpfile, or
> >
> > - in locations not included in your dump.
> >
> >Depending on what kind of activity has been going on in your
> >repository, non-complete dumpfiles can be very complex. Whenever you
> >dump less than the whole repository, you can run into trouble.
> >
> >Does this clarify what the problem is?
>
> Yeah I was afraid that something like this would rear its ugly head. Its a pretty
> complex tree.
> I had thought that the directories I had excluded were "mutually exclusive" in
> the sense that they didn't touch any parts of the tree that I wanted to keep.
> The main reason for the excludes are to get rid of a commit of generated
> documentation files (think 50MB of 4-5k .html files - subversion did not like
> this...) Of course before this migration was made, those files were deleted, then
> the tree was copied, yadda yadda yadda...
>
> >
> >It's not clear what 'svnadmin dump' should do about this. Including
> >data in the dump (the copy sources) that was not requested in the dump
> >has its own problems. After all, in order for the new repository to
> >reflect the copy history accurately, it would have to put that source
> >data somewhere in the new repository too. But where? You didn't ask
> >for it to be dumped; logically, it should not be carried across when
> >you load the dumpfile.
> >
> >Sorry, I'm not trying to say "talk to the hand" :-), I'm just not sure
> >what the right solution is. You might be better off just importing a
> >tree than trying to load history from an incomplete dumpfile.
>
> Unfortunately since its a rather complex project I really need to maintain the
> revision history, and do to the nature of what's happening with the company it
> must be migrated out of the current repository it is in.
>
> >
> >-Karl
> >
>
> --
> James Lamanna
>
> >James Lamanna jamesl@appliedminds.com> writes:
> >> Joshua Varner wrote:
> >> > On 8/24/05, James Lamanna jamesl@appliedminds.com> wrote:
> >> >
> >> >>I tried asking this on svn-users, but I never got a response...
> >> >>And its quite an important issue preventing me from moving forward.
> >> >>
> >> > Sorry for the delay
> >> > Here is the original thread from users:
> >> >
> http://subversion.tigris.org/servlets/BrowseList\?list=users&by=thread&from=357391
> >> >
> >> >>I've attached a svnadmin load log that fails.
> >> >>
> >> >>The dumpfile used was created with:
> >> >>svnadmin dump
> >> >>/export/repositories/ami |
> >> >>svndumpfilter include --drop-empty-revs TouchTable TouchTableSDK |
> >> >>svndumpfilter exclude --drop-empty-revs
> >> >>TouchTable/branches/API/TouchTable/API-Prelim/apiPrelimDoc
> >> >>TouchTable/branches/API/designDocs
> >> >>TouchTable/branches/API/TouchTable/API-Prelim/Comments
> >> >>TouchTableSDK/Comments TouchTable/branches/demo/n > ttdumpfile4
> >> >>
> >> >>This was then loaded into a brand new repository.
> >> >>
> >> >>The failures appear to be "missing transactions" and thinking that files
> >> >>are not there. By the looks of things it almost seems like the revision
> >> >>numbers are wrong where it is looking for the files.
> [snip..]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 25 16:12:13 2005