Before you spend time -- what think you (and Bert) of the suggestion
to have branches simply be in their own repository (its own directory
of the name of the branch)?  I know it's not how you do it today, but
please just imagine it in terms of the UI -- would it work?  Ok, there
might be issues diffing versions *between* branches -- is that a
frequent requirement?  Actually, they might both be in your
package-cache so may be could be diff'd there?

If you're willing to try, I'll pitch in to help save your time (for
example, set up the repositories, etc.).



On Thu, Aug 9, 2012 at 11:07 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
> 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
>
>
>
>