Hi, Erik and Philip!
On 9/23/05, Erik Huelsmann <ehuels@gmail.com> wrote:
> On 9/23/05, Ivan Zhakov <chemodax@gmail.com> wrote:
> > On 9/23/05, Philip Martin <philip@codematters.co.uk> wrote:
> > > Erik Huelsmann <ehuels@gmail.com> writes:
> > > > BTW: which part of the 'remove copyfrom-url and copyfrom-rev' do you
> > > > consider non-atomic? Modifying an entry is done with 1 call into
> > > > svn_wc__modify_entry.
> > >
> > > I don't know whether Ivan's change would have introduced an atomic
> > > problem, it's quite possible his change will be been OK. If he thinks
> > > svn_wc_delete2 is the best place to do then he may be right.
> > My opinion that in any case no atomic problems will be indroduced.
> > After discussion I can restate my question: Is this logic (about
> > cleanuping fields) should applied for all situation when scheduled
> > modifed from replaced to deleted or only when entry deleted by
> > svn_wc_delete2()?
>
> I think it should always clear those fields: there is no use for those
> values, since they can only apply to items which are scheduled for
> addition to version control. A 'D'elete state implies the item is
> already under version control.
Ok.
> I have the following change sitting in my working copy, which takes
> care of Philip's atomicity concerns. It has 1 problem though: I can't
> remove the copyfrom_url value from the entry which is being deleted,
> since we can't marshall a NULL value into a logfile. That's why those
> lines are commented out in the patch below. If we change
> svn_wc__modify_entry the way Philip describes, that's solved and some
> of the other fields can be removed from the SVN_WC__LOG_MODIFY_ENTRY
> tag.
I have done this in r16230. Please review it. I cleanup unused fields
when entry gets schedule==deleted. So you can remove all fields from
SVN_WC__LOG_MODIFY_ENTRY except SVN_WC__ENTRY_ATTR_SCHEDULE.
> Also, I think that some of the svn_io_check_path() arguments should be
> joined with 'parent' to turn them into absolute values. I have only
> tested this changed from the $PWD, so that I didn't notice the problem
> at first.
My expierence says that relative path can produce problems. But may be
I am wrong.
--
Ivan Zhakov
Received on Fri Sep 23 18:38:41 2005