Hi David,
As for the RAM requirements of cvs2svn ... the OOo test conversion
worked in 16 GBytes RAM here.
Heiner
David Anderson wrote:
[Cc'ing the dev list for info]
Kai Backman wrote:
Here is the message I got from the KDE migration dev. You guys know
the current cvs2svn codebase a bit better, are were the changes he
mentions integrated upstreams?
I don't know the codebase intimately, but the hacks DannyB did should at
least be obtainable from somewhere. I'll get on to him about it.
I have a preliminary access to a server we could use for the
conversion itself, and I'm working on getting us a separate
production server. If you have a conversion server around, that would
be fantastic as well. We'll not be using Collab.net for the
production servers, it will be on a separate site/provider.
Right now, there is a lot to consider before even thinking of the actual
migration. While we do other stuff, we can of course try to get our
hands on the best machine we can, as I suspect it'll be a long haul to
convert, but what we need to figure out right now is a strategy for the
migration, and get going on the tools port.
So my question for you is if you have already got your hands on the
CVS repos material itself? I'm pulling down a filtered version from
go-oo.org that excludes the web and some binary data. We might
actually want to export only this subset, it contains all the
important development data. It might not make sense to pollute the
SVN repos with web commits.. We will also need to do some
reorganization once the repos is up, there are some legacy issues
that we can conveniently take care of during the transition.
Could you detail these issues? I'm fairly new to OOo, and could use the
info.
Reorganization can be done at the same time that we do the actual
switchover. If you feel so inclined, I have fair experience of
reorganizing entire histories to fit a new structure (I did so for
Freenet, to fix their misuse of branches).
As for the contents, we might as well pull the website and stuff down
with it, if we want that to appear in the repository. Do you not want
the website to be under version control any more? And what of the
binaries? I understand there are a lot of things like vendor tarballs
that are stored in version control. While this is not a problem in
itself for Subversion, it might be interesting to remove them to limit
the work of cvs2svn, and to limit the resulting repository size.
Let me know what your status is (if your exam period is over).. :-)
I haven't finished yet. I'll be done on friday. Maxime is already done,
but will probably be partying until then as well :-).
> Yes, I can recommend a machine with a lot of memory. For KDE 256GB
> RAM were enough though.
Ouch. We're going to have fun finding that kind of machine :-).
> Take your time and double check the result. When we converted, we
> noticed too late that about thousand files were missing from random
> branches. But svn is pretty cool in allowing to repair that
> afterwards. For that we created a full dump, fixed the dump with
> the information we had and refilled a new repo with the fixed dump.
> Then we stopped our live svn, readded the newly added revisions,
> moved the repo over and started svn again. For the developers this
> took less than 5min - even though the full fixing was 4 days ;)
I suspect we'll have less problems, thanks to the grooming the OOo team
and Collabnet have given to it over the years. However, advice well taken.
I've already had a chat with our resident cvs2svn experts, and we've
come up with a tentative procedure for a migration with minimal
downtime, which'll need a little work but should be relatively painless
thanks to the extra data cws provides.
I'll get back to you on Friday or Saturday. See ya.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jens-Heiner Rechtien
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
