On Thu, Feb 15, 2007 at 05:47:03PM +0000, Bruce Stephens wrote: > But get_revision is disappointing: > > format_version "1" > > new_manifest [c3e572809bffd0011e4b8d061baed9ce7f06b36f] > > old_revision [4259cbe62814990e1c3b0fbec8ed99c32da1cdea] > > add_file "change" > content [da39a3ee5e6b4b0d3255bfef95601890afd80709] > > old_revision [b89448d98d849e7e77aa21bc5b682bd5e51f3ad7] > > add_dir "db" > > add_file "another" > content [da39a3ee5e6b4b0d3255bfef95601890afd80709] > > add_file "db/db_file" > content [f1d2d2f924e986ac86fdf7b36c94bcdf32beec15] > > It's mentioning both the old revisions, so why is it adding all these > things again? The only thing that's changed is the new file "change", > surely?
Because that's how revisions work -- they give the changes against one parent, and then the changes against the other parent. Monotone has cleverness to figure out which files are actually new, etc. > Is this how it's supposed to be? Is this how it must be, because it > makes this way of working infeasible, I think (at least for me)? What about it is infeasible? With long-lived branches it can create more data transfer overhead, which is a little annoying, but nothing specific to merge_into_dir... -- Nathaniel -- In mathematics, it's not enough to read the words you have to hear the music _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
