[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: <kfogel_at_collab.net>
Date: 2003-11-22 02:47:06 CET

Philip Martin <philip@codematters.co.uk> writes:
> The schedule replace versus schedule add stuff still appears to be a
> bit confused,

Ya think? :-)

One of my ambitions (I'd better file an issue about this) is to do a
tags-search for 'svn_wc_schedule_add' in conditionals, and see in how
many places it ought to be accompanied by an 'svn_wc_schedule_replace'.

In fact, I did this tags search, and came up with quite a few
suspicious spots.

> Let's do a file as well as a directory

The more the merrier!

> 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?

> 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? :)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 22 03:30:57 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.