[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 7825 - in trunk/subversion: libsvn_wc tests/clients/cmdline

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-11-22 19:10:52 CET

kfogel@collab.net writes:

>> The directory shows up as status 'R' but the file shows up as status
>> 'A'. I think they should be the same, but I don't know whether it
>> should be add or replace.
> Actually...
> I think 'A'dd is a more appropriate answer (although the code is
> currently doing 'R' for the directory case, I guess).
>> Next problem, if the "rm -rf wc/foo" step is omitted from the recipe
>> then the directory no longer shows up as status 'R' but instead shows
>> up as status 'A' just like the file. Again I think they should be the
>> same, but I don't know if add or replace is correct.
> If the object hadn't been committed after being rm'd, then 'R'. But
> since it has, 'A'.
> Does this make sense to you too?

Yes. I suspect the reason for the 'A'/'R' anomaly is that the code is
making a decision based on the result of svn_io_check_path() rather
than svn_wc_entry(). This is a common problem in the wc code, there
is already an issue about copy making the same mistake.

>> The final problem is really a separate issue. Whether the directory
>> is status 'R' or status 'A' running update causes both the file and
>> the directory to become unversioned. This is obviously a problem with
>> the update logic that removes entries in state deleted. I think what
>> should happen is that entries that are schedule add/replace should
>> remain but should have the deleted state cleared. Perhaps schedule
>> replace should be converted into schedule add as well.
> Yep.
> Whew. Want to file the issue? :)

I have a patch :)

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 22 19:11:42 2003

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.