Greg Stein <gstein@lyra.org> writes:
> > + if (is_full_proplist)
> > + {
> > + /* If the caller passed a definitive list that represents all
> > + of the file's properties, we need to compare it to the
> > + current 'pristine' list and deduce the differences. */
>
> Why? If a full proplist is provided, then just install the darned thing. The
> current code generates diffs between the full set and the current set, and
> then later applies those diffs to generate the full set.
"Install the darned thing"? You mean *merge* the darned thing. The
user might have local propchanges that conflict!
The problem was not wanting to rewrite the universe.
Here's what we currently have: a function that takes a "list of prop
deltas" and merges them into both the pristine and working props. If
any working props conflict, a .prej file is created. All of this
stuff is done via our 'journal first, then execute' techniques.
That's swell. But now I have two callers of svn_wc_install_file: one
of them is the update-editor: it has file and dir batons that are
caching propchanges during the edit. The other caller is
svn_client_switch(), which receives a *full* proplist from
RA->get_file().
So with my back to the wall, I had to choose an interface for
svn_wc_install_file. After talking with Karl, we decided that the
interface should take a list of props, and a flag would indicate
whether it was a list of deltas, or a "complete" list.
In the case of the update-editor (which is by far the most common
caller), it can just pass the baton's propchanges straight in, and the
function can pass the propchanges straight to the
property-merging-routine. Smooth as butter.
In the other case, things were uglier. svn_client_switch converts a
hash of complete props into a list of complete props. Then it passes
the list to svn_wc_install_file, with the flag set. Seeing that it's
a new "complete" list, svn_wc_install_file loads up the currently
installed pristine proplist, and calls a pre-existing routine which
creates a list of changes *between* the two complete lists. Then it
passes the list of propchanges to the merging routine.
I think the proper solution (someday) is to rewrite the property merging
routine itself. All the work in the previous paragraph should
probably be done *inside* the prop-merging routine, and this routine
should take either type of list.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:07 2006