To add to the wall of text, keep in mind that when I say "shut down the app" --- remember Trac is a web app. If you have control over DNS or the web server itself, then you can easily make it so people can't pop in and change anything while you are working. But if you don't shut down SVN as well, then people who have their TortoiseSVN clients mucking around may affect any migration you are performing.
Also note that Trac will rebuild the revision history from scratch as needed, so you don't have to shut down SVN while you are moving Trac and vice-versa. However, if you are reproducing either item from a snapshot it is vital that you don't allow anyone to upversion SVN or Trac while you're making the switch over. The best approach in my mind is declaring a ban on SVN checkins when migrating SVN, ditto with Trac. And when you are at the point of "switch over" make sure you have switched over by shutting off the services on the old machine so there is no confusion. DNS cacheing can be the enemy. And one more thing: Don't forget your SMTP server for email notification. One presumes that you're able to use the same one as before, but if that's changing, make sure you test that out. Vincent On Jan 26, 3:45 pm, Vincent Polite <vpol...@socialnetconnect.com> wrote: > 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 <flatfen...@gmail.com> 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 trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
