Dotted revno "algebra"

[Eric Siegerman]

On Fri, 2010-05-07 at 09:05 +0200, Vincent Ladeuil wrote:
>>>>> Eric Siegerman <lists08-bzr at davor.org> writes:
>     > I only need
>     > to resort to qlog for more complex situations.
> 
> Yeah, so, already you acknowledge that log falls short to help for
> complex graphs. :-(

For sure.  But most of the time, the graph *isn't* complex; at
least, the subgraph I'm looking at isn't.  It's usually a
straightforward feature branch:

    ... - A - B - C - D - E - F - ...
           \                 /
            \-G - H - I - J-/


>     > A more precise statement of the property I value is that "X.Y"
is
>     > equivalent to "X.Y.0".
> 
> You're still handwawing a bit here since there is no good ordering for
> Y.

I don't see it as handwaving; I see it as ignoring irrelevant
details of the implementation.  Sure they're relevant to the
implementer, but not to me, personally, as a user.  That's
because, as I said, I don't really care about Y; because, if a
case is complex enough that I might care in theory, I don't in
practice; because in such a case I have to bring in the big guns
anyway, i.e. qlog.

But again, that's the exception, not the rule; or at least, I've
found it to be so.

Remember Alan Kay's dictum?  "Simple things should be simple;
complex things should be possible."

Currently both parts of that are fulfilled, via log and qlog
respectively; but numbering revnos by merge point would, for me
at least, make the simple case far less simple.


>     > I don't need the revno to tell me where the merge point is; "bzr
>     > log -n0" *shows* me that.
> 
> Hmm, except when that outputs MB of data and the merged point is pages
> (10ths) from the revno itself.

That's what "less" is for.  It's trivial to mark my place and
search for another rev of interest ... as long as I know which
rev that is! <rimshot/>


>     > (Not sure why I care about the branch
>     > point more than you seem to do, but, well, I do care about it.)
> 
> That was my question, why do you care about it. Really, I'm sure there
> are valid reasons and I'd like to understand them.

I don't know if I can quite put it into words, I'm afraid.  The
best I can say is that I want to know where a feature branch came
from, as much as I want to know where it went (which now that I
reread it, is just restating in different words what I said
before).  I guess I want to know what state the trunk was in when
I decided it was time to work on that feature (or bug fix) in the
first place.

Now that I've got the question in mind, I'll pay more attention,
to see if I can come up with anything more concrete.  (Might be a
while though; I don't have any source-controllable projects on
the go at the moment.)


> The debate is still opened about [...]
> finding a good solution for Y...

Well, if a way is found to make those interior revno components
more useful to me than they are now, that'd be a bonus.  But if
no such enhancement is made, I won't feel short changed; I don't
have a problem with the status quo.

I *will* feel short changed if such an "enhancement" comes at the
price of losing properties I *do* value -- which is why I chimed
in on this thread in the first place :-/

  - Eric