Re: [Monotone-devel] roster restrictions and implicitly included parent directories

[Nathaniel Smith]

On Sun, Feb 26, 2006 at 11:20:26PM -0700, Derek Scherger wrote:
> So the conversion to rosters added proper support for directories and 
> all was good right? It's clearly a great addition, but it does 
> complicate things a bit. In particular it broke a few tests that use 
> restrictions to include only partial trees.
> 
> For example:
> 
>       $ monotone add foo foo/bar foo/baz
> 
> creates a new directory foo (assuming it wasn't already tracked), and if 
> this was the first command of a new project it also creates a new root 
> directory for the project.
> 
>       $ monotone status --brief
>       
>       added
>       added   foo
>       added   foo/bar
>       added   foo/baz
> 
> The first line there is the root directory addition. Now
> 
>       $ ~/monotone/mainline/monotone st --brief foo
>       monotone: fatal: std::logic_error: roster.cc:497: invariant
>       'I(has_root())' violated
>
> This problem would come up because restricting the tree to foo excludes 
> the root directory addition. The original solution to this problem was 
> to have a restriction implicitly include the parent directories of 
> anything it includes. This is what the current mainline rosters code 
> does and the reason we haven't seen such problems.
> 
> I have a patch (that was an experiment as much as anything) that removes 
> this "solution" from  the mainline code. This patch makes some small 
> changes to the tests that break to make sure that containing directories 
> exist before restricting to things below them. For example:
> 
>       $ monotone add foo
>       $ monotone commit
>       $ monotone add foo/bar
>       $ monotone add foo/baz
>       $ monotone commit foo/bar
> 
> This works because the commit of foo creates it and the root directory 
> so later restricting to things under foo does not require any excluded 
> additions.

I don't understand from this what exactly your patch does -- it
sounds like it simply removes the klugey workaround we put in, and
then instead of making a proper fix, it just changes the tests so
they don't run into the problematic cases? :-) E.g., with your patch,
if I run 'monotone st --brief foo', like in your example above, do I
now get an invariant failure?  If not, why not?

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco