Re: What to do about our repository (was: svn.collab.net is now running 1.5.0-alpha2)

On Mon, Mar 3, 2008 at 10:11 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:

> 2. We dump/load our repository with no filtering and run
> 'svnmerge-migrate-history.py' on it. Same benefits as the previous
> case except our node-origins cache is optimized, our merge tracking
> internals are in sync, and we'll know if we have bogus proto-forms of
> merge tracking property syntax because they might cause this whole
> process to fail. Nobody needs to checkout new working copies.

I guess this is my vote, #2. There will be other people with
mergeinfo props in their repository and this will help us learn if
there are things to fix when this happens. Setting aside the issue of
bogus props, either #1 or 2 are closest to what our users need to do,
so again it will help identify anything about the process that does
not work right or needs to be better.

I could even see us doing #1 for a few weeks and then doing #2
(without needing to re-run the svnmerge-migrate script the second
time.

Finally, we do not have a ton of branches with work going on that
would pick up some great benefit from being fancier. We are probably
better of staying close to what we are telling our users to do with
their repositories.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org