On 2012-08-09, at 16:52, Chris Muller wrote:

>>> Eliot, is there some way to solve your issue without enumerating all
>>> filenames of a repository?
>> 
>> I'm out of my depth here.  Bert is the authority.  But I do know it is
>> absolutely necessary to take account of the branch name.  Here's why:
>> 
>> a) finding the head of a branch is extremely difficult if it is lumped in
>> with the trunk.  For example in VMMaker the head of VMMaker is 284 while the
>> head of VMMaker.oscog is 196.  So VMMaker.oscog is buried far down the list.
>> This is sort-of sufferable by me, but not by newbies who likely won't find
>> it.
>> 
>> b) the "is the package modified" highlighting (emboldening and underlining)
>> is entirely misleading if branches and trunks are lumped together.
>> 
>> So please reconsider.  Monticello used to separate trunks and branches. The
>> change that lumped them together make the system difficult to use for some
>> packages (and I hope you agree VMMaker is kind of important).
> 
> I just want to understand better, not make anyone's life harder.  The
> breakage can be "solved" by adding
> 
>   MCRepository>>allPackageAndBranchNames
>       ^ self allPackageNames
> 
> but the reason I brought this up is because I put a lot of work into
> getting MC's treatment of repository's cleaned up and under control so
> that they all can work uniformly.  This change puts us back to
> supporting only FileBased repositories, which are slow because they
> can only do their work by enumerating all their files.
> 
> ..I can't see that Monticello has ever had any notion of branches --
> just its ancestry structure.  There's no "Branch" class of any kind
> and no methods (other than the ones recently added).  Not even a
> comment about it anywhere.
> 
> We already have at least 3 fields that make up a MCVersionName
> (Package, author, version) and now this puts in a 4th.  It increases
> complexity of the code and even adds a new Preference all just for
> sorting items in one list widget -- this responsibility would seem
> fall more on MCRepositoryInspector.
> 
> If there is no other way, fine, but currently it's mysterious and
> breaks the system, so I thought I'd at least ask..
> 
> Thanks.


Branches are a little known but old feature of Monticello; they used to work pretty much only by a convention on file names. That's why there is no code to deal with them explicitly, the code was just careful to preserve a file name that differed from the package name. With the recent addition of MCVersionNames that behavior was made explicit so now we need to be careful when we want just the package name and when we need the package with its branch appended.

- Bert -