On Thu, Aug 9, 2012 at 7:52 AM, Chris Muller <asqueaker at gmail.com> 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.
>

The preference was only introduced to avoid changing the (new) default
behaviour.  Bert thinks (and I agree) that the preference isn't necessary.
 I just haven't got around to removing it yet.

If there is no other way, fine, but currently it's mysterious and
> breaks the system, so I thought I'd at least ask..
>

Well, let's eliminate the mystery and fix it. Branches are really important
and the UI needs to provide good support.  Let me eliminate the preference
at least.


>
> Thanks.
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120809/b04a0634/attachment.htm