Migration in general is a tricky thing if not managed properly. That said, Trac isn't particularly resource intensive. Would be curious to know if moving Trac will actually get you any measurable value in terms of offloading the workload from the decrepit Unix box. :)
My take with Trac migrations is to make sure you are understanding what you are actually migrating. Many people confuse migrating Trac with migrating SVN vs. migrating the Trac database, accounts, and maybe associated plugins. Migrating the Trac database and tickets is really straight forward. My approach to this process is installing a new version of Trac on your windows machine, and when you have been able to test that the system "works" on that new box, to migrate the database and any artifacts like ticket attachments and the wiki (which I believe there is a migration tool of sorts to help with that, although I admit, I've only used the tool in a Unix->Unix migration, not a Unix->Windows migration so the mileage may vary). This actual data migration should occur during a period where the database is not in use. If you happen to be using the same backend, like a mysql server->mysql server dump, then you have the ability to lock down/shut down the database - do an appropriate copy, and then reconstitute the database on the other machine. As long as you control access to the system such that there is no overlap in use between the two systems, this shouldn't be much of a problem. The good news is that you can practice this migration using snapshots of the original database and then "officially migrate" when you are satisfied there are no hitches in the process. SVN then is the more significant issue (in my mind at least). IIRC, Trac has some restriction/preference about SVN running on the same machine as Trac does? I'm not sure about the reason behind that restriction, as I would think that FileMounts/Shortcuts/etc would be stable enough provided that there wasn't some ridiculous geographical difference between the Trac server and the SVN machine. But that's besides the point. You will also want to bake in the time to migrate your SVN repository as well. Just to offer my perspective, I'm as big a Windows apologist as you might ever find in the open source community. I enjoy administering Windows servers because I know them well enough to not get myself into a situation that requires any sort of voodoo magic. :) But I have to admit, it seems a tad nonsensical to intentionally add variables like changing the OS underneath Trac (and possibly SVN?) just to feed some corporate ego about using a Windows machine. The hardware required for Trac to run is pretty much a pittance. Slap some variation of Linux on an old machine that might otherwise be only good as a doorstop, and you're pretty much good to go.... that all said, in addition to the migration pieces, you will want to make sure that your SVN and Trac backup strategies are implemented properly in the Windows environment. If you are already in a well developed backup practice with your Linux machine, then being able to make snapshots of the relevant portions of your Trac and SVN (and Apache pieces) will make things trivial. Also remember that you will need to migrate the user authentication methodology. i.e. if you are using LDAP on Apache in conjunction with the Trac Account Manager, you will need to verify that your accounts are migrating properly. LDAP makes things mostly trivial, especially if you're already using something against an existing repository - Active Directory counts :). But if you are hand managing accounts on the core Unix side and in Trac, then you may want to see if there's some value in going against AD if you're not already. Good luck. Take lots of notes and snapshots, and really take your time in planning out your various steps and dependencies. At the end of the day, you should have a very manageable punch list of items that you can just walk down, and as long as you appropriately plan what to do in those, "Oh crap" moments that may invariably happen, you will be fine. This really won't be so bad. Hope you are able to cull some knowledge from the ramble. Best, Vincent Polite On Jan 26, 6:23 am, Flatfender <[email protected]> wrote: > > P.S. @Matt: If you don't want to help with Windows issues, why do you > > answer at all? :) > > To clarify my original response. > > The first of which is that my experience is that Windows gets no love > from the open source community and you'll most likely get less > responses, that is a big deal when the only support you have is from > other members of the community. PHB's that don't understand FOSS need > to understand that, they may not be able to enjoy having their cake > and eating it too. They want FOSS, but don't want to devote the > resources to it. Or they get bogged down in their little Microsoft > only world. Just because you can get Python, Apache, Postgres, Mysql, > etc running on windows doesn't mean it will be as easy to deploy the > same app windows as it is Linux. And you'll find less people with > experience and desire to help trouble shoot the differences. > > Now, I don't run windows servers if I don't have to, I do maintain > some, but I don't have any FOSS apps running on them. What I meant by > the life is too short for me to be a windows admin, is I generally > won't try to run FOSS on Windows, and consequently I wouldn't have > windows environments setup to try to troubleshoot on. I never said I > didn't want to help. What I said was help will be harder to find and > that is a big deal. I answered to make that specific point. > > Matt P. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" 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/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
