On Tue, Oct 22, 2002 at 02:31:44AM +0200, Branko Cibej wrote:
> Daniel Berlin wrote:
> >On Mon, 21 Oct 2002, Marko Macek wrote:
>...
> >>Well, here it is, based on revision 3371
> >>
> >>Changes:
> >> - now requires an existing svn repository instead of creating one
> >>
> >>
> >Why?
> >This used to be how it was, and it was specifically changed to *not*
> >require one.
>
> I think it's better to create the repository beforehand. If nothing
> else, you can then tweak the DB_CONFIG parameters to suit your needs
> before the conversion. This could mean a big difference in conversion
> times. It also opens the door for incremental imports, which might not
> be a bad thing.
It should work both ways. It is extremely handy to just have the tool
create one for you.
> >>Issues:
> >> - currently breaks the multi-pass mode, because it uses some
> >> in-core data which needs to be moved to the temp files
> >
> >I did this too, and greg got annoyed.
> >:)
>
> So much for Greg. At least branch and tag conversion works now. :-)
> Don't worry, I'm sure Mark will get around to moving those hashes elsewhere.
The tool uses multiple passes and stores state in the files because it is
intended to scale to any size repository. If I've got a 50 gig repository,
then no way would I want to restart the whole thing if something breaks in
pass 4. You simply fix whatever the problem was, and restart at pass 4.
When testing my latest change, I flipped the code back and forth and just
reran pass 4. It was quite helpful.
Arguably, the multi-pass stuff is just for development, but I see a future
point where you run the tool, find it doesn't quite figure out some commits
properly, so you tweak a .conf file to alter the instructions/operation of
the tool, then you rerun with the modified config.
In fact, I'd argue that pass 4 is too large. It should figure out the
commits and drop those into a file that defines the commit groups. A new
pass 5 would read that file and perform the commits. This would allow a
human or other tool to operate on, and tweak, the file which is defining the
commits.
Because the patch breaks the multi-pass concept, I don't believe it should
be applied. It is way cool that it solves the branches and tags, but I would
suggest providing a patch which adds some of the basic substrate first. Then
fix up the in-core data thing, and provide another patch on top of that.
When Daniel first provided a patch to do the bulk of the work in pass 4,
there was a lot of extra stuff in there for caching (among other items).
That was yanked out as his patch was added in. I hoped that he would fix up
the areas that got yanked (I forget all the details), but he hasn't had
time/inclination to do so.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 24 04:00:13 2002