Re: [Monotone-devel] merge_into_dir wanted behaveour?

[Timothy Brownawell]

On Wed, 2006-09-20 at 18:31 +0200, Johan Bolmsjö wrote:
> Hello,
> 
> I don't know if this is the right mailing list for this question but here it 
> goes. I have some small utility libraries that I don't wish to package for 
> system wide installation that I use in other branches. I tried to use 
> merge_into_dir and this works fine but if I try to propagate changes made to 
> the merged into branch inside the destination branch back. Well then the two 
> branches will get the same content.
> 
> I later read the manual and it clearly states this behaveour. It also says 
> that the purpose of merge_into_dir is to allow this kind of structure.
> 
> Example:
> 
> branch util contains "a.py", "b.py"
> branch prog contains "c.py"
> 
> If I merge into dir b:util -> b:prog util/
> 
> I have in b:prog:
> c.py
> util/a.py
> util/b.py
> 
> Now I figure it's common to do bug fixes to "util" when "prog" is being 
> developed. One would like to be able to propagate "prog" back to "util" and 
> expect only the changes made to "util" files be propagated to "util".
> 
> Is there some rationale behind the current behaveour or is it that it's just 
> impossible to do this with the current monotone design?

It's not possible with how we currently handle file lifecycles. Once a
file is deleted, it can never come back. So a prog->util propagate like
you want would delete everything from 'prog' that didn't originally come
from 'util', and then the next propagate util->prog would be forced to
delete those files in prog as well. (I believe there have been some
thoughts floating around about fixing this, but nothing concrete yet.)

There'd be the additional difficulty of making our merge code understand
that propagates can be asymmetric, but that should be more difficult
than impossible.

Tim

-- 
Free (experimental) public monotone hosting: http://mtn-host.prjek.net