Karl Fogel <kfogel@collab.net> writes:
> Jim Blandy <jimb@zwingli.cygnus.com> writes:
> > Ahh, I just thought of the right answer to this question:
> >
> > In the approach you suggest, you're basically re-implementing all the
> > logic in svn_fs_merge within DAV. This means that the filesystem has
> > packaged up that logic in a way that's not useful to you. If you
> > could think of an alternative, easy-to-understand interface that would
> > allow you and the commit process to share the logic, that would be the
> > best outcome.
> >
> > I guess the logic isn't that complex, so the duplication still isn't a
> > big deal. It's just finesse points.
>
> Yeah, good point.
>
> But: Greg, were you aware that svn_fs_merge() is not only for trees?
> It just takes three roots and three paths -- those pairs can result in
> any kind of object. So maybe svn_fs_merge() gives you the information
> you need after all. (Or maybe not? Let us know...)
I think it doesn't, because Greg does his merge with no base node
whatsoever. He never ever looks at the base revision. He stashes
exactly the information the merge needs from the base revision in
those wc properties, so he never actually needs the base revision
itself.
So any function that operates on three actual nodes isn't useful to
him; he only needs two nodes, and some administrative info.
Is that right, Greg?
Received on Sat Oct 21 14:36:26 2006