I think I understand you.  The *contents* of the files are where all
the meat of the package is, not in the filename itself.

This is true with one exception:  When merging, Monticello looks for
the ancestor of a package based on its ancestor's filename embedded in
the package, which is why the (very common) scenario I mentioned, the
same developer creating two branches off the same version in different
repositories, is a major pain.

I can understand why Monticello does this, it assumes the files are
never renamed.  But they sometimes need to be, as in the above
scenario.  Which is why I suggest that packages be named with their
UUID as one node of the filename; it would seem to alleviate the
problem completely.

> That would be a long filename ;)

But that's no problem though, right?  OS's today can handle 200+
character filenames..

 - Chris

On 5/3/07, Norbert Hartl <norbert at hartl.name> wrote:
> On Wed, 2007-05-02 at 21:00 -0400, Chris Muller wrote:
> > Filename hell with Monticello occurs when one developer copies a
> > repository to another computer, creates two separate branches of
> > functionality on both computers (the original and the copy).
> > Monticello chooses the same filenames for the very different invidual
> > packages, causing merging to be virtually impossible or, at least,
> > very painful.
> >
> Ok, but copying a repository and edit it simultanously always conflicts.
> My concern where based on the "branch" you can do with renaming the
> file. I just recognized that there is only a package and this is stored
> in a repository. It doesn't matter which filename those commits have
> but Monticello Browser gives you separate view.
>
> > If Monticello would include the UUID in the filename, that might solve it..
> >
> That would be a long filename ;)
>
> Norbert
>
>
>