Re: [Monotone-devel] info during merge on files dropped on one side receiving changes on the other side?

[Nathaniel Smith]

On Thu, Jul 13, 2006 at 04:38:50PM +0200, Marcel van der Boom wrote:
> Yeah, this is _sometimes_ a solution. Sometimes, because it's not  
> always possible to construct such output apparently. In our case for  
> example the msg appears:
> 
> mtn: warning: restriction excludes directory 'blah/blah/1'
> mtn: warning: restriction excludes directory 'blah/blah/2'
> ....
> mtn: misuse: invalid restriction excludes required directories

This seems weird.  Could you give more details on what exactly you
did?  A reproducible test case would be especially nice :-).

> I was thinking more in terms of something like:
> 
> $mtn propagate one two
> mtn: propagating one -> two
> mtn: [source] 9ea04ac3c5931d8be40cc3da634708c793b017c4
> mtn: [target] 4c48584b4c452245b4ec0fa788f49fb1b16e5d5c
> mtn: info: file /path/to/onlyhere.txt changed in 'one' but dropped in  
> 'two'
> mtn: info: file /another/file.txt changed in 'one' but renamed in  
> 'two' to /something/else.txt
> mtn: info: file /again/nothere.txt changed in 'one' but renamed and  
> dropped thereafter in 'two'
> mtn: [merged] 3a778819764ea9045b8640eee78ae4d4bb61a9dc
> $
> 
> and similar in 'mtn show_conflicts' output i guess. Not sure if the  
> last two info lines make sense though. Such output would save a lot  
> of time, since it spits out the filenames to investigate manually for  
> the 'functional' changes in branch 'two' versus 'one' which monotone  
> cannot determine by itself.

You know, I was all sighing and getting ready to write an apologetic
email about how yeah, this was totally something we should do, but we
haven't because we don't know how to make it work, since in a delete
case we don't have the other side to compare to and thus can't _tell_
whether a file was changed, maybe we could add that if/when we add
resurrection support...

Then in the shower I went "doh, we could just look at the marks".
Handy, this *-merge thing; maybe I should learn how it works one of
these days :-).  We can just check if the file being deleted has any
marks in its uncommon ancestor set, and there we are.  Making this
spit out a warning at roster_merge time would be easy, but sort of
wrong; better would be to extend the roster_merge_result structure to
give us somewhere to stash such warnings.  Could you file a bug so we
don't forget?

Also, what kinds of changes are worth warning about?  Content,
obviously, but what if it's been renamed on one side and deleted on
the other, or had an attr modified on one side but deleted on the
other, are those worth warning about?

-- Nathaniel

-- 
"If you can explain how you do something, then you're very very bad at it."
  -- John Hopfield