Greg Stein <gstein@lyra.org> writes:
> > In the long run, I'd hate to see ra_local relegated to an obsolete
> > test harness.
>
> Quite true. I hear ya. I bet it will always exist, but I'm hoping it will be
> the black sheep of the family.
Heh.... if I buy into this argument, then maybe I shouldn't care that
ra_local does commits differently than ra_dav. Seriously! :)
.
> > > > [ long (semi-sarcastic :-) spiel about converting ra_local ]
> >
> > Since it's clear that you're not going to budge, I think you've mostly
> > managed to talk me into rewriting the fs commit-editor to match your
> > model. It's still a good model, I like it.
>
> Hmm. I'm hoping changes will come from agreement rather than avoiding an
> "immovable object." I actually feel quite bad when it seems that people
> relent rather than agree. The part that is even worse for me, is that it
> happens enough that I notice. It makes me apprehensive about whether I'm too
> stubborn, too inflexible, etc. I hope that I'm open, but it invariably
> devolves to "prove it is better" which isn't nearly as diplomatic :-(
Well, next week we'll be face-to-face, so you'll have plenty of
opportunity to make me emphatically agree that the ra_dav commit
system is inherently more attractive. You're not too stubborn --
you're very open and empathic -- but I'm still not persuaded that
ra_dav's system has more technical merit.
Lemme think. Hm. I see problems with *both* systems, really.
In your last mail to Jim, you said that the problem was that the
filesystem provides no interface that answers the question: "I want
to change REV:PATH. Is that allowed? Am I up-to-date?" Therefore,
you're doing the node-rev-id checks yourself.
But I think now that this was the original heart of my objection to
ra_dav's technique: the fs *does* have a function that comes awfully
close. svn_fs_merge answers the question: "I want to change all these
REV:PATH objects that I've assembled into a tree. Is that allowed?
Am I up-to-date?" It's just the *plural* form of the function that
you've been wanting.
So, let me summarize my complaints:
* I think it's definitely inefficient for ra_local to keep calling
fs_merge on an ever-growing tree, every time it gets one change.
Why call a "plural" routine when you really want a "singular" one?
It's wasteful.
* I think it's bad that ra_dav is running id-comparison logic on
individual items, when that logic *already* exists inside the
filesystem. (We've already found a few bugs last week in
fs_merge's logic -- down at the low-level 'id distance computing'
routines. I want to think that if we fix them, that *all* ra
layers conflict-detection will be equally stable as a result.)
Perhaps we can synthesize a new commit-system that we *both* use, sort
of a compromise?
* the ra layer ignores the base_rev arg given to replace_root.
Instead, it just creates a txn based on the youngest rev.
* we break out the node-id-comparison logic into a shared internal
func, and use it to create a new fs function call
svn_fs_merge_item(). (and rename svn_fs_merge() into
svn_fs_merge_tree())
* as changes (with base_revs) trickle in, the ra layer uses
fs_merge_item to check for conflicts.
* finally, we call fs_commit_txn... which internally uses the
"plural" function to merge against whatever the new 'youngest'
tree is (in case it changed during the commit.)
This system addresses both of my complaints above... and hopefully
it's close enough to what you're already doing that you'd like it
too. I think this system has the most Technical Merit.
> > But hey, it's M2 week, so we're all a little tense. Nevertheless,
> > Greg, you're the epitome of calmness under stress... a real cool head
> > in these arguments. Thanks. :)
>
> I hear the tense bit :-) ... I've been spending a lot of time in front of
> the computer, and not enough on (ahem) planning/doing other things in life.
> To get both done, it means little sleep :-)
Yeah, my wife is going to kill me. I need a vacation. :)
>
> But I tend to think of them as "discussions." It is impossible for me to be
> angry with somebody for something they believe in. I tend to understand
> others' positions, so I can see where they're coming from; I just tend to
> disagree with those positions :-)
Definitely... no anger here at all. Just friendly debate.
Received on Sat Oct 21 14:36:26 2006