On Wed, Sep 3, 2008 at 10:54 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> 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'm in the process of doing this for my personal repo. So I'm planning to give away my knowledge (maybe scripts if that's reasonable) when TG's migration comes.
>> 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." > which is one of the reason's probably making a migration script isn't a great idea. After all it will just be several calls to hgimportsvn. >> 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. ;) > I'm not sure if this is a good idea. I'll prefer a band-aid approach (quick so it won't hurt) having two versioning systems wil just confuse people. Which branches are you talking about? private-local branches? Since both systems understand patch really well, migration shouldn't be an issue, running svn diff, and then patch on the mercurial checkout should be a problem. The only case where this should break is if you have moved files and that will be an issue just if you moved a lot of files. > 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. > I don't really know how the current svn/trac users are manage, but mercurial uses the same approach as svn. So it's probably just an issue of moving the current names into the new db. >> 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. > In my opinion the hard part will be trac, as the migration will probably have to export all data, and then into the new trac environment. The hardest part will be to determine what "all data" is for each project. > --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 -~----------~----~----~----~------~----~------~--~---
