On Mon, Apr 25, 2011 at 4:23 PM, Zed A. Shaw <zeds...@zedshaw.com> wrote:
> On Mon, Apr 25, 2011 at 04:08:26PM -0400, Richard Hipp wrote: > > On Mon, Apr 25, 2011 at 3:55 PM, Joshua Paine <jos...@letterblock.com > >wrote: > > > > > So this sounds like maybe has more to do with the changing definition > of > > > leaf? > > > > > > FWIW, I would *not* expect that merging a branch would close it. In > > > fact, I routinely assume that it does not, as I merge back and forth > > > sometimes between trunk and feature branches to apply bugfixes or > > > freestanding subfeatures from one to the other. > > Again, I'm not talking about branches (those are leaves with names, they > should not close). I'm talking about leaves, those are unnamed and > mostly revision merge junk that has to be dealt with (or it was). > > > This goes back to my comments of the other day - that the definition of > > "leaf" is subtle, and that I have had to change the definition of "leaf" > a > > few times over the history of Fossil to deal with issues that have > arisen. > > Zed's problem seems to originate in the most recent "leaf" definition > > change. > > Alright, so how were you using the old definition of leaves, then > suddenly not seeing this change cause your leaf count to explode? Were > you always doing something different with leaves I'm not? > > Ok so it was a recent change that caused my output to suddenly explode, > now for the problem: > > > The current definition of "leaf" is a node that has no primary > (non-merge) > > children in the same branch. > > Definitions are pointless. No. Definitions are vitally important. This whole mess came about because of my initial failure to pay close attention to the definition of a leaf - because different parts of the code (written years apart from one another) used different definitions for what a "leaf" was, resulting in inconsistent behavior, and user confusion. The most recent changes to the definition of leaf were in an attempt to unify the definition - to get all operations and screens and commands of Fossil to mean the same thing when they say "leaf". That ideal has probably not been completely achieved yet, but we are closer. > I could define and define all day long and > nobody would be able to *use* them. Translate the above statement into > how I would use it to do this: > > 1. Joe blow commits and that causes a leaf. > 2. I pull from joe blow and merge. > 3. .... > 4. There are only named leaves being shown as branches. > Fine. That is a legitimate request. Translated, you are asking for Fossil to identify leaves as nodes which have no children (of any kind) in the same branch. That is probably a good idea. But it is not what the code does now. And it is apparently also not what Joshua wants it to do - he thinks that the operation above should result in two leaves, one containing Joe Blow's change and the other on the main line of development. Me? I don't care one what or the other since I seldom if ever use the concept of a "leaf". "Leaf" was an important concept in early versions of Fossil because I guess (incorrectly) that it would be important. But in practice (or at least in my practice) it has turned out to be far less important than I original suspected. Notice that the default menu bar no longer contains links to the pages that show all leaves; I took those links out some time ago when I figured out that leaves are not as important as other concepts. > > Then I won't care what kind of graph table algorithmic definition you > come up with, so long as the above sequences of commands don't change > without warning. > > Additionally, none of the documentation on closing a branch is right. > I've had to go in and use the UI to add the "closed" tag and they're > still there. I've done everything and the only thing that's worked is: > > fossil tag add --raw closed aaf334335 > I have not had any trouble using the UI to close a leaf. Can you please provide additional information about the problem you are experiencing so that I can reproduce it and hence fix it? > > That's a usability nightmare. I can't tell people that they have to go > through this complex 4 step process involving an esoteric command "tag > add" to close (not intuitive) just to do a merge when every other RCS > does it in one or two. > > > Suggestions on how to please everybody? No - a configuration option is > not > > the right answer; there needs to be a single, unified definition of > "leaf". > > Stop changing it? Or, better yet, change it but quit leaking those > changes out to the user interface. "Leaf" is purely a UI concept. Fossil does not use leaves internally for anything itself (that I can think of off hand.). Fossil keeps track of leaves purely so that it can tell the user what the leaves are. This gets back to the original problem. Everybody has an intuitive idea of what a "leaf" is. But the concept of "leaf" turns out to too subtle to be easily captured by intuition. My own intuition shifted over time (measured in years) and with experience, resulting in earlier parts of the code identifying leaves in slightly different ways than later code. Then more recently, I have tried to use the term "leaf" more consistently, resulting in the unfortunate side-effect that Zed suffered an explosion of leaves. I can change the definition one more time (the last time, we hope) so that the Zed leaf explosion goes away. Or I can leave it as is. But let's not go thrashing back and forth in a vain effort to please both Zed and Joshua at the same time, which is not possible. What shall it be? > Having my repo suddenly explode with > leaves because, 1 year ago leaves worked one way, but now 1 month ago > they work totally different, just won't work. If you have to change it > like this then consider making big announcements on the list that it's > changing and how to deal with the change, and include it in the rebuild > so people migrate cleanly. > > > -- > Zed A. Shaw > http://zedshaw.com/ > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
