On 22 aug 2006, at 09:31, Nathaniel Smith wrote:
Hrm. That's a... creative way of doing things :-). I don't think we can support this particular mechanism in any useful way (and in fact, it's already pretty sketchy -- don't you run into problems when there have been any adds/removes/renames?).
Not really, i use this to prevent problems actually. I dont want to go learn all 150 people monotone, so i just say "you can do anything in these directories but dont touch the _MTN dir, that's mine"
When the time comes i go into these workspaces, do a mtn status and take it from there. Usually mtn revert for the missing files first to make the noise a little less. Depending on what mtn status tells me continuation is either take the log (of mtn status plus a diff later on) and discuss with the user, throw away their local changes, or "steal those changes" and integrate them into the product or some other action. This process repeats over time and works well for us. Having clients fill my patch queue is not bad :-)
That just means we should have a cleaner way to support this use case, though. To start with, what's wrong with 'diff -r <revision>'? Would it be useful to have 'status -r <revision>'?
diff -r <revision>:nothing, i use it. In practice i think i just got into the habit of just doing mtn diff since the revision file had already the base rev ;-)
status -r <revision>:thinking about it, this is propably the crux. this would be *very, very* useful. (although i saw that the output of this changed in .29 to a more human oriented format?)
marcel -- Marcel van der Boom HS-Development BV -- http://www.hsdev.com So! webapplicatie framework -- http://make-it-so.info
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
