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

RE: [merge-tracking]: Don't combine repos mergeinfo with local mergeinfo if the later is modified.

From: Paul Burba <pburba_at_collab.net>
Date: 2007-03-19 23:09:14 CET

Thanks for the review Dan, A few questions below.

> -----Original Message-----
> From: Daniel Rall [mailto:dlr@collab.net]
> Sent: Monday, March 19, 2007 12:59 PM
> To: Paul Burba
> Cc: SVN Dev; Kamesh Jayachandran
> Subject: Re: [merge-tracking]: Don't combine repos mergeinfo
> with local mergeinfo if the later is modified.
>
<snip>
> > Index: subversion/libsvn_wc/props.c
> > ===================================================================
> > --- subversion/libsvn_wc/props.c (revision 23893)
> > +++ subversion/libsvn_wc/props.c (working copy)
> > @@ -2549,3 +2549,53 @@
> > }
> > return FALSE;
> > }
> > +
> > +svn_error_t *
> > +svn_wc__props_modified(svn_boolean_t *modified_p,
> > + const char *path,
> > + apr_hash_t **which_props,
> > + svn_wc_adm_access_t *adm_access,
> > + apr_pool_t *pool) {
> > + SVN_ERR(svn_wc_props_modified_p(modified_p, path, adm_access,
> > +pool));
>
> I'd rather expect svn_wc_props_modified_p() to be calling
> this new routine, rather than vice-versa. If WHICH_PROPS is
> NULL, we could bail out of the old svn_wc_props_modified_p()
> logic earlier.

I do see that calling svn_wc_props_modified_p() from my new function
leads to a lot of redundant code being executed with older WC formats
that don't support prop caching, so I agree that should be fixed. But
where in svn_wc_props_modified_p() were you thinking of calling
svn_wc__props_modified()? If we call svn_wc__props_modified() from
svn_wc_props_modified_p() the former is always going to execute code
similar to that in the "Last ditch attempt:" section of the latter
(which it goes to great lengths to avoid), that seems equally bad to
what I have now...

Possibly I could move the "old svn_wc_props_modified_p() logic" into
svn_wc__props_modified(), but keeping the "easy outs" from that code
would get a bit ugly.

Thoughts?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 19 23:09:47 2007

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.