[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 1228 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/libsvn_subr trunk/subversion/libsvn_ra_local trunk/subversion/libsvn_client trunk/subversion/libsvn_ra_dav

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-02-13 08:13:07 CET

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

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.