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