We ran the setup similar to what Dale describes, replicating about ten user databases (full db_rep_def and db_subscription) for about two years, and to be honest it was both a pain to setup and always caused us problems after a switch. The actual problems, apart from that the switch took nearly 10 minutes, was always that after a switch (including quiesce of the two repservers X 2 times that took ages), the replication never started to flow from the new Primary to the new Replicate on at least 2-3 databases every time. So we had to drop the setup for these and materialize them from scratch to get the replication going again.
But since about nearly a year now, we run the setup described by Luc, without having to even touch any of the repservers during a switch, only stopping and starting the rep_agents. And this works like a charm 
Initially we have to setup replication in both direction of course
Our steps in a switch looks like this and takes us less than 30 seconds these days :
1. Set both PRIM and SECO to unknown
2. Throw all users out of PRIM
3. Create a rs_ticket on each database on PRIM.
4. Wait for the tickets to arrive on SECO. Once they are all there, we know we have consistency.
5. Stop replication agent on PRIM
6. Remove Secondary Truncation Point for SECO
7. Set Secondary Truncation Point for SECO
8. Reset zeroltm for SECO
9. Start replication agent on SECO
10. Create rs_ticket on each database on SECO
11. Wait for the tickets to arrive on PRIM. Once they are all there, we know replication is working.
12. Remove secondary truncation point on PRIM
13. Set SECO to PRIM and vice versa
14. Done!
Note : step 1 and step 13 is our way to direct our applications against the Primary ASE (apart from IP and DNS), having a non-replicated database/table that all our apps is checking against which ASE is Primary and Replicate. And on top of this, we have a login_trigger, that will refuse login if the ASE is set to SECO (=Replicate)
/Mike