> Does anyone have a migration plan? I mean, a series of commands and > configurations that would be run to migrate our repository?
Not yet. I brought up the question before comming up with a detailed plan because I didn't want to waste time on a detailed plan if we weren't really going to make a change. > I did the change on one project here, but I had to use hgimportsvn to be able > to get everything and the initial process seemed to be really slow (this > project only had 2700 revisions). Yea, that is my experience too, it's pulling every changeset, and creating a new repository. But at least it only has to be done once. And it supports pulling just one section of the svn tree out into it's own repository, with just the history for that "branch." > Also, for how long will we keep a read-only SVN repository (hgpullsvn can help > keeping it up to date)? Because if we have branches and work being done on > SVN (and don't have the same "plan" that TG followed on the main repository) > we don't necessarily need / can / want to commit before the move. Having the > read-only repository would help creating patches to apply over a new checkout > using mercurial, when the "time constraint" allows the developer / company / > team / whatever to do that (i.e., if I am in the middle of a certification / > validation process I can't change the repository immediately). I'm not 100% sure I follow you here. What is your suggestion? I think it makes sense to maintain a svn repository that has reasonably current code for several months at least. The question is how often to merge changes over to that repository, and how fine-grained the history of that repository needs to be. Would it be good enough to just do a svn checkin nightly from the current mercurial tip? -- perferably only if all the tests pass. ;) Or should we try to automate it so every changeset is pushed over separately? > I know all this sounds too corporate, but that's the kind of planning I do > everyday for a bank and for companies in the human health market... > Can we get the migration done using a batch? I mean, one big script that woul > dbe run to migrate our official repository, including users and etc.? If it > is too hard, maybe part automated and part explaining how to change commands > to accomplish the whole change. Well the user bit would be the hardest, and I don't think it's too bad, even if we have to do some manual bits there. It's not like we have hundreds of active commiters. > This would allow the change for personal repositories to follow the same > process in the future... (Also extremely useful to document things and for > widget authors that will want to migrate.) Yea, we should definitely document how the conversion is done, and how people can move their TG related projects to our new hg+trac system when they want to make that change. --Mark --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
