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

RE: More SVN status bugs

From: Bill Tutt <billtut_at_microsoft.com>
Date: 2001-01-11 22:10:31 CET

> From: Karl Fogel [mailto:kfogel@galois.collab.net]

> "Bill Tutt" <billtut@microsoft.com> writes:
> > * ${SVN_PROG} delete-force ${TEST_DIR_1}\A\D\H\omega
> >
> > Registers the delete in $(TEST_DIR_1)/SVN/entries with a filename of
> > "A\D\H\omega" and an ancestor of: "anni/A\D\H\omega"
> > Doesn't touch ANYTHING in $(TEST_DIR_1)/A/D/H/SVN/entries

> Okay; working on, thanks for noticing this! (Time to get that path
library fleshed out. :-) ).

That wasn't the problem. A\D\H\omega was indeed deleted when I passed in
the -force option.
The problem was that the "omega" entry still existed in
A\D\H\SVN\entries after the delete was finished.
(Well, that and a deleted marker showed up in
$(TEST_DIR_1)/SVN/entries.)
I haven't run into any actual problems because of the silly paths we're
currently generating.

> > * adding a file (newfile1), and then deleting it before you commit
it
> > results in the correct state in the entry structure for it, but
there's
> > an unneeded else that marks this file as just being added:
>
> > Index: status.c
> > ==================================================================
> > RCS file: /cvs/subversion/subversion/libsvn_wc/status.c,v
> > retrieving revision 1.24
> > diff -u -r1.24 status.c
> > --- status.c 2001/01/09 00:05:22 1.24
> > +++ status.c 2001/01/11 08:52:54
> > @@ -108,7 +108,7 @@
> > status->prop_status = svn_wc_status_added;
> > }
> >
> > - else if (entry->state & SVN_WC_ENTRY_DELETED)
> > + if (entry->state & SVN_WC_ENTRY_DELETED)
> > {
> > status->text_status = svn_wc_status_deleted;

> Hmm. If we get rid of the 'else', then the result of the second
> conditional body might simply override the result of the first. In
> other words, something that was marked as *both* added and deleted
> would only show up as deleted. Which would be fairly random-if the
> conditionals' order were reversed, then it would be adds overriding
> deletes instead of the other way around.

> I think the 'else' is deliberate. Here's the reasoning:
> 1. If an entry is just added, you want to report it as added.
> 2. If an entry is just deleted, you want to report it as deleted.
> 3. If an entry is _both_ added and deleted, that can only mean one
> thing: the entry was deleted and *then* added. That is, in the
> working copy, someone removed a file, then they added a new file under
> the same name. (Had the order been reversed, then the entry would
> simply have been removed-there's no point even talking about a file
> that was added and then un-added. It never happened.) So the idea is
> that status reports it as added.

Well, the scenario I'm talking about is the "add, delete" sequence for a
file without an intervening commit.
It sounds like your suggesting keeping the else, and moving the bugfix
into someplace in the delete handling logic.
i.e.:
* When deleting a file in the WC state:
   If the file has already been marked as an add, hard delete the
meta-data for the entry, since the user never wanted
   To commit the data in the first place.

I think that makes sense, I'll leave fixing up the delete stuff in
someone else's more capable hands.

Bill
Received on Sat Oct 21 14:36:19 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.