Re: [Monotone-devel] Re: comments on net.venge.monotone.workspace-merge.migration

[Marcel van der Boom]

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