Just wanted to send you all a simple "Thanks!" for providing such a great tool! The more I use monotone, the more I like it. There is always an adjustment period, during which time I should have probably kept my mouth shut on the development list. ;-) Strike my suggestion for INI-style output, for example; I like what monotone currently uses.
One thing I wish was easier to do was fix mistakes regarding commits to branches, when I forget to add a new '-b NEWBRANCH' option, for example. Monotone does the right thing and happily commits to the current branch. I realize I could add a cert named "branch" with the "NEWBRANCH" value, but then the revision belongs to two branches, and I'm not sure what type of chaos that might cause for Monotone. I've tried deleting the old branch cert from my local repository (no contact w/an outside repository just yet), but then "monotone status" complains that the revision has no ancestors. :-P. So, obviously, I have stuff to learn about how monotone handles these things. Since I'm not too many revisions in (just checking in upstream tarballs and patches), I could always recreate it (a bit more carefully this time). Any concensus on what people like to name version-based branches? RFQDN.project-VERSION or RFQDN.project.VERSION? Where VERSION = alphanumerics and '_'? (I write this as my 12 month old son has discovered that playing on the stairs is Great Fun! At least he's only two steps up, at this point. I'll start worrying when he crawls up past the "bumps and bruises" potential energy step, which I estimate to be step three...) Anyway, thanks again, folks! Great tool! -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
