# 
# 
# patch "ChangeLog"
#  from [404a9c337d70dd6fcb677b0e0d36425f02e814a9]
#    to [249f9095770249cb4cd141464f3129fc7876ea77]
# 
# patch "commands.cc"
#  from [44215afc9d7c1dace2bae56ae8427e4e906e1251]
#    to [72f5fa6d4e6a72199a3a1612baa7977f3ab72ea3]
# 
============================================================
--- ChangeLog	404a9c337d70dd6fcb677b0e0d36425f02e814a9
+++ ChangeLog	249f9095770249cb4cd141464f3129fc7876ea77
@@ -1,5 +1,9 @@
 2005-01-24  Timothy Brownawell  <address@hidden>
 
+	* commands.cc (update): Remove fixme comment.
+
+2005-01-24  Timothy Brownawell  <address@hidden>
+
 	* commands.cc (update): Allow backwards/sideways updates.
 	tests/t_update_to_revision.at: remove XFAIL
 
============================================================
--- commands.cc	44215afc9d7c1dace2bae56ae8427e4e906e1251
+++ commands.cc	72f5fa6d4e6a72199a3a1612baa7977f3ab72ea3
@@ -2894,23 +2894,6 @@
         % r_chosen_id % app.branch_name);
     }
 
-  // FIXME_ROSTERS: In the old (pre-roster) code, we supported updating to
-  // any revision in the graph, anywhere; if there was a path to get there,
-  // we'd synthesize a changeset to get there. This was a little easier to
-  // work with in pre-roster monotone because we merged changesets, not
-  // rosters.
-  //
-  // To do this using rosters' default "mark-merge", we'd need to
-  // synthesize a marking map using a fake ancestry graph. It's
-  // conceivable, but it's a fair amount of work, and it's not clear that
-  // many people used it, nor that mark-merge is ideal for the task. It
-  // might make more sense to make a different merger for this
-  // case. 
-  //
-  // Anyways, for the time being we're only implementing "forwards
-  // updates". That is, you can only "update" to new base revisions which
-  // are descendents of the base revision you have in your working copy.
-
   app.db.get_roster(r_chosen_id, chosen_roster, chosen_mm);
 
   std::set<revision_id>