[Monotone-devel] Re: monotone diff failure

[Bruce Stephens]

Lorenzo Campedelli <address@hidden> writes:

> I wish to report a problem I have with the presence of equal files
> in a monotone repository.
>
> The small script I attached shows the problem.  In short, if two
> files are both changed to make them equal, then monotone diff says
> that one file was changed, while the other was deleted.

You're right, that's nasty.

> I studied the sources a little bit and I think the problem comes
> from tha handling of path_id_bijection in patch_set.cc.
>
> A comment there says the following:
> "
> // nb: we preserve the bijective property of this map at the expense of
> // possibly missing some add/delete matching cases. for example, if an
> // identical file is deleted as one path name and added as two new path
> // names, we will record it as an add + a move, rather than anything
> // more clever.
> "
>
> But in case two files are equal in the tree, the relationship
> between the pathname and the hash cannot be a bijection, right?

Yes, that's true.  I'm not sure how common identical files are, but
it's clearly not good that the system can't cope with it.

> I tried to find a solution to this, maybe by using a one-to-many
> association from hash to pathnames, but the current bijection
> concept seems very deeply rooted in the code around there...

My guess (without having read the source---so I may be quite wrong) is
that the system is only using the manifests, and that's not enough.
I'm guessing it's doing that because even in the working directory
(where it has MT/work which tells it what really happened) it gets it
wrong.  I'm guessing that MT/work isn't recorded in the database, so
manifests are all that are available.

> Is it possible to get around this problem? Am I the only one who
> happens to have files with the same content in a tree stored in
> monotone?

I suspect it'll take a slight redesign.  With any luck, it's one of
the things to be improved in the changeset branch.

[...]