You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Josef Wolf <jw...@raven.inka.de> on 2004/03/06 22:09:30 UTC

Removed dir in repos with local modifications result in strange behavior.

Hello!

Today, I experienced a strange behavior. Maybe some kind of soul could
check whether this is a bug or maybe it was my mistake.

I had two WCs of a (production) repos. In the first WC, I made local
modifications to a file named server/config/boot.txt, but I have not
commited them bacause I was not sure about the change. Some days later
I decided to _completely_ get rid of this server subdirectory. So I
issued a "svn rm server" from the second WC, which I committed.

Then I came back to the first WC (the one with local mod's in a file
which parent directories were already removed in the repos). Here is a
(commented) capture of what happened:

    jw@raven:~/sandbox/misc> svn up
    U  notice
    subversion/libsvn_wc/update_editor.c:780: (apr_err=155000)
    svn: Won't delete locally modified directory ''
    subversion/libsvn_wc/adm_ops.c:1669: (apr_err=155012)
    svn: File 'boot.txt' has local modifications

OK, I forgot about the local modifications and it is a good thing that
svn reminds me. But how come that the locally modified directory don't
have a name? 

    jw@raven:~/sandbox/misc> svn diff
    Index: server/config/boot.txt
    ===================================================================
    --- server/config/boot.txt     (revision 38)
    +++ server/config/boot.txt     (working copy)
    @@ -110,7 +110,7 @@
    [ contents deleted ]

Well, the diff contained exactly what I expected. I don't need the whole
directory anymore. So my plan is to revert the changes and "svn up" to
get rid of the directory. So let's revert:
    
    jw@raven:~/sandbox/misc> svn revert server/config/boot.txt
    Reverted 'server/config/boot.txt'

This was the only modification. So "svn up" should work now. But:

    jw@raven:~/sandbox/misc> svn up
    subversion/libsvn_wc/update_editor.c:780: (apr_err=155000)
    svn: Won't delete locally modified directory ''
    subversion/libsvn_wc/adm_ops.c:1878: (apr_err=155012)
    svn: Left locally modified or unversioned files
    jw@raven:~/sandbox/misc> svn st
    !      .
    M      BUILD
    ?      server/config
    !      server

Note that the server/config directory has a question mark as if it was never
under svn control. But this just _can't_ be true because I just reverted
a change in a file from this directory. Now I tried to revert the whole
directory:

    jw@raven:~/sandbox/misc> svn revert server/
    jw@raven:~/sandbox/misc> svn st
    !      .
    M      BUILD
    ?      server/config
    !      server

Ough! Still not enough? So revert the _current_ dir. (note that I should
loose local modifications to the BUILD file here):

    jw@raven:~/sandbox/misc> svn revert .
    jw@raven:~/sandbox/misc> svn st
    !      .
    M      BUILD
    ?      server/config
    !      server

Ough?? BUILD is still modified? And the directory is still in a strange
state? OK, try recursive.

    jw@raven:~/sandbox/misc> svn -R revert .
    jw@raven:~/sandbox/misc> svn st
    !      .
    M      BUILD
    ?      server/config
    !      server

WTF? Nothing changed?!?

    jw@raven:~/sandbox/misc> svn up
    subversion/libsvn_wc/update_editor.c:780: (apr_err=155000)
    svn: Won't delete locally modified directory ''
    subversion/libsvn_wc/adm_ops.c:1878: (apr_err=155012)
    svn: Left locally modified or unversioned files

Not that I really expected that this would help...

    jw@raven:~/sandbox/misc> svn up .
    At revision 39.

But _this_ makes me really curious... How come "svn up ." be _that_
different from "svn up" without the dot? And why does it revert the
changes "svn -R revert ." was not able to revert?

    jw@raven:~/sandbox/misc> svn up
    At revision 39.
    jw@raven:~/sandbox/misc> svn st
    jw@raven:~/sandbox/misc> 

At last...
This is what I would have expected after the first "svn revert".

PS: Thanks to all contributors. Subversion is a _great_ piece of software!

-- 
-- Josef Wolf -- jw@raven.inka.de --

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Removed dir in repos with local modifications result in strange behavior.

Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:

> On Sat, 2004-03-06 at 18:06, Philip Martin wrote:
>
>> I do think we should consider changing update: when a locally modified
>> item is encountered during delete, update should unversion, warn, and
>> continue.  There should only be an error if the unversioned item left
>> behind causes an obstruction to a later add.
>
> Ooh, that's a nice idea.  Hmmmm.

Hmmm some more.  Perhaps we should distinguish locally modified and
unversioned, and stop at locally modified but continue at unversioned.
The reason being that the user may want to record the local
modification and it is much harder to do that once the item becomes
unversioned (directory properties in particular).

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Removed dir in repos with local modifications result in strange behavior.

Posted by Ben Collins-Sussman <su...@collab.net>.
On Sat, 2004-03-06 at 18:06, Philip Martin wrote:

> I do think we should consider changing update: when a locally modified
> item is encountered during delete, update should unversion, warn, and
> continue.  There should only be an error if the unversioned item left
> behind causes an obstruction to a later add.

Ooh, that's a nice idea.  Hmmmm.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Removed dir in repos with local modifications result in strange behavior.

Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-03-08 at 15:33, Josef Wolf wrote:
> But hey, the unversioned item in the versioned directory was on svn's
> global-ignores list. Why don't update ignore this item and proceed with
> the removal of the directory?

Because the global-ignores list does not mean "these files are of no
consequence and can be deleted without regret."


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Removed dir in repos with local modifications result in strange behavior.

Posted by Josef Wolf <jw...@raven.inka.de>.
On Mon, Mar 08, 2004 at 08:03:01PM +0000, Philip Martin wrote:
> Josef Wolf <jw...@raven.inka.de> writes:
> 
> > On Sun, Mar 07, 2004 at 10:57:46PM +0000, Philip Martin wrote:
> >
> >> >> That's a different error, it doesn't mention a file.  I think you have
> >> >> an unversioned file or directory somewhere under server/config.
> >> > If there is an unversioned file, I'd expect "svn st" to mention it?
> >> server/config is unversioned, status won't look inside it.
> >> 
> >> >> It is true, you ran "svn up" after the revert and it deleted
> >> >> server/config and made it unversioned.
> >> > If this were true, server/config should have been removed...
> >> No, because it contains an unversioned item.
> >
> > This is inconsistent.
> 
> The basic principle is that update will only remove items from the
> disk if they can be retrieved from the repository.  This means that if
> you have a versioned directory that contains an unversioned item, then
> update will not be able to remove that directory from the disk.  It
> will make the versioned directory unversioned, which deletes it from
> the version control and will leave it on the disk.

But hey, the unversioned item in the versioned directory was on svn's
global-ignores list. Why don't update ignore this item and proceed with
the removal of the directory?

> The only problem I
> see is that the update aborts with a "left unversioned" error, I think
> it would be better to warn and continue the update.

Yes, of course.

-- 
-- Josef Wolf -- jw@raven.inka.de --

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Removed dir in repos with local modifications result in strange behavior.

Posted by Philip Martin <ph...@codematters.co.uk>.
Josef Wolf <jw...@raven.inka.de> writes:

> On Sun, Mar 07, 2004 at 10:57:46PM +0000, Philip Martin wrote:
>
>> >> That's a different error, it doesn't mention a file.  I think you have
>> >> an unversioned file or directory somewhere under server/config.
>> > If there is an unversioned file, I'd expect "svn st" to mention it?
>> server/config is unversioned, status won't look inside it.
>> 
>> >> It is true, you ran "svn up" after the revert and it deleted
>> >> server/config and made it unversioned.
>> > If this were true, server/config should have been removed...
>> No, because it contains an unversioned item.
>
> This is inconsistent.

The basic principle is that update will only remove items from the
disk if they can be retrieved from the repository.  This means that if
you have a versioned directory that contains an unversioned item, then
update will not be able to remove that directory from the disk.  It
will make the versioned directory unversioned, which deletes it from
the version control and will leave it on the disk.  The only problem I
see is that the update aborts with a "left unversioned" error, I think
it would be better to warn and continue the update.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Removed dir in repos with local modifications result in strange behavior.

Posted by Josef Wolf <jw...@raven.inka.de>.
On Sun, Mar 07, 2004 at 10:57:46PM +0000, Philip Martin wrote:

> >> That's a different error, it doesn't mention a file.  I think you have
> >> an unversioned file or directory somewhere under server/config.
> > If there is an unversioned file, I'd expect "svn st" to mention it?
> server/config is unversioned, status won't look inside it.
> 
> >> It is true, you ran "svn up" after the revert and it deleted
> >> server/config and made it unversioned.
> > If this were true, server/config should have been removed...
> No, because it contains an unversioned item.

This is inconsistent.

Either there _was_ an unversioned item withhin server/config, then
server/config should not be assigned the unversioned status in the
first place.

Or there was _no_ withhin server/config unversioned item, then the directory
should have been removed.

Current behavior seems to be somewhat half-baked.


I tried to make a simple reproduction recipe and can now see what caused
the problem. It was an emacs backup file that prevented "svn up" from
working as expected. This looks like a bug to me, since emacs backup
files are in my global-ignores configuration setting. Below is the
reproduction recipe attached. If the line with the tilde is removed
from this command sequence, the "svn up" with the attached comment
succeeds (as expected).

  cd ~
  rm -rf testrepos wc1 wc2
  export REPOS=~/testrepos
  svnadmin create $REPOS
  svn co file://$REPOS wc1
  mkdir -p wc1/foo/bar
  echo blah >wc1/foo/bar/baz
  echo blah >wc1/file1
  (cd wc1; svn add foo file1; svn ci -m first; svn up)
  svn co file://$REPOS wc2
  echo blah >>wc2/foo/bar/baz
  echo blah >>wc2/foo/bar/baz~
  echo blah >>wc2/file1
  (cd wc1; svn rm foo; svn ci -m remove; svn up)
  (cd wc2; svn up)
  (cd wc2; svn revert foo/bar/baz)
  (cd wc2; svn up) # this line should succeed in removing the directory
  (cd wc2; svn up)
  (cd wc2; svn up)

-- 
-- Josef Wolf -- jw@raven.inka.de --

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Removed dir in repos with local modifications result in strange behavior.

Posted by Philip Martin <ph...@codematters.co.uk>.
Josef Wolf <jw...@raven.inka.de> writes:

> On Sun, Mar 07, 2004 at 12:06:46AM +0000, Philip Martin wrote:
>> Josef Wolf <jw...@raven.inka.de> writes:
>> 
>> It's a poor message, it means
>>    Won't delete locally modified sub-directory within directory '.'
>
> But it don't say '.', it says ''. And I would have expected 'server'.

As I said, it's a poor message.

>> That's a different error, it doesn't mention a file.  I think you have
>> an unversioned file or directory somewhere under server/config.
>
> If there is an unversioned file, I'd expect "svn st" to mention it?

server/config is unversioned, status won't look inside it.

>> It is true, you ran "svn up" after the revert and it deleted
>> server/config and made it unversioned.
>
> If this were true, server/config should have been removed...

No, because it contains an unversioned item.

>> It's not "strange" it's incomplete (read the docs)
>
> _What_ is incomplete? There was only _one_ local modification in this
> directory. This modification was _reverted_. The repos says that the
> directory has to die. I don't see what is incomplete here...

The 'incomplete' status is one result of an interrupted update.

> Does this mean that an unversioned directory will block updates? You must be
> kidding...

Unversioned items will block deletes, this is deliberate.

I haven't looked at the documentation lately, are these things not
covered?

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Removed dir in repos with local modifications result in strange behavior.

Posted by Josef Wolf <jw...@raven.inka.de>.
On Sun, Mar 07, 2004 at 12:06:46AM +0000, Philip Martin wrote:
> Josef Wolf <jw...@raven.inka.de> writes:
> 
> >     jw@raven:~/sandbox/misc> svn up
> >     U  notice
> >     subversion/libsvn_wc/update_editor.c:780: (apr_err=155000)
> >     svn: Won't delete locally modified directory ''
> >     subversion/libsvn_wc/adm_ops.c:1669: (apr_err=155012)
> >     svn: File 'boot.txt' has local modifications
> >
> > OK, I forgot about the local modifications and it is a good thing that
> > svn reminds me. But how come that the locally modified directory don't
> > have a name? 
> 
> It's a poor message, it means
>    Won't delete locally modified sub-directory within directory '.'

But it don't say '.', it says ''. And I would have expected 'server'.

> >     jw@raven:~/sandbox/misc> svn revert server/config/boot.txt
> >     Reverted 'server/config/boot.txt'
> >
> > This was the only modification. So "svn up" should work now. But:
> >
> >     jw@raven:~/sandbox/misc> svn up
> >     subversion/libsvn_wc/update_editor.c:780: (apr_err=155000)
> >     svn: Won't delete locally modified directory ''
> >     subversion/libsvn_wc/adm_ops.c:1878: (apr_err=155012)
> >     svn: Left locally modified or unversioned files
> 
> That's a different error, it doesn't mention a file.  I think you have
> an unversioned file or directory somewhere under server/config.

If there is an unversioned file, I'd expect "svn st" to mention it?

> >     jw@raven:~/sandbox/misc> svn st
> >     !      .
> >     M      BUILD
> >     ?      server/config
> >     !      server
> >
> > Note that the server/config directory has a question mark as if it was never
> > under svn control. But this just _can't_ be true because I just reverted
> > a change in a file from this directory.
> 
> It is true, you ran "svn up" after the revert and it deleted
> server/config and made it unversioned.

If this were true, server/config should have been removed...

> > Now I tried to revert the whole
> > directory:
> >
> >     jw@raven:~/sandbox/misc> svn revert server/
> >     jw@raven:~/sandbox/misc> svn st
> >     !      .
> >     M      BUILD
> >     ?      server/config
> >     !      server
> >
> > Ough! Still not enough? So revert the _current_ dir. (note that I should
> > loose local modifications to the BUILD file here):
> 
> No, revert is non-recursive by default (read the docs)

That's why I issued a "svn -R revert ." below. Read ahead.

> >     jw@raven:~/sandbox/misc> svn revert .
> >     jw@raven:~/sandbox/misc> svn st
> >     !      .
> >     M      BUILD
> >     ?      server/config
> >     !      server
> >
> > Ough?? BUILD is still modified? And the directory is still in a strange
> > state?
> 
> It's not "strange" it's incomplete (read the docs)

_What_ is incomplete? There was only _one_ local modification in this
directory. This modification was _reverted_. The repos says that the
directory has to die. I don't see what is incomplete here...

> > OK, try recursive.
> >
> >     jw@raven:~/sandbox/misc> svn -R revert .
> >     jw@raven:~/sandbox/misc> svn st
> >     !      .
> >     M      BUILD
> >     ?      server/config
> >     !      server
> >
> > WTF? Nothing changed?!?
> 
> I cannot reproduce that, can you?

This is the capture from the KDE-konsole, so there should not be any typo
problems. I'll try to reproduce this.

> >     jw@raven:~/sandbox/misc> svn up
> >     subversion/libsvn_wc/update_editor.c:780: (apr_err=155000)
> >     svn: Won't delete locally modified directory ''
> >     subversion/libsvn_wc/adm_ops.c:1878: (apr_err=155012)
> >     svn: Left locally modified or unversioned files
> 
> You have an unversioned directory (server/config) in server.

That's strange. Usually "locally modified" has the semantics of an item
under version control with local modifications. This time "locally modified"
has the semantics of "unknown item". Are you sure that the error is really
about an unversioned item? How can one (simple-minded as me) deduce from the
above error message that there is an unversioned subdir in a versioned dir?

Hey, all I want is to get rid of this damn dir. Last time I got into this
situation I made a "rm -rf damndir". This was a big mistake. I had to
completely remove the WC. This time I tried to use only svn commands to
resolve the problem. Was not a big difference on the first glance...

> > Not that I really expected that this would help...
> >
> >     jw@raven:~/sandbox/misc> svn up .
> >     At revision 39.
> 
> It's not the explicit "." that makes the difference it's the repeated
> updates.

Oh, I made three updates. They all did not help. Might be some sort of luck
that the fourth update (which was the first I tried with the dot) fixed the
problems...

> - update attempts to delete server/config but fails because
>   server/config contains an unversioned item.  server/config gets left
>   as unversioned.  The update fails.

Does this mean that an unversioned directory will block updates? You must be
kidding...

> I do think we should consider changing update: when a locally modified
> item is encountered during delete, update should unversion, warn, and
> continue.  There should only be an error if the unversioned item left
> behind causes an obstruction to a later add.

I think you are on the wrong road here. it was absolutely correct for
(first) update to error out when it encontered the local modifications.
But it should have left the directory as it was before the update. This way
resolve would have a chance to clean things up.

The problem was that (first) update made some modifications to the WC
which prevented (second) update (which was issued after "svn revert")
to do its job properly.

-- 
-- Josef Wolf -- jw@raven.inka.de --

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Removed dir in repos with local modifications result in strange behavior.

Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2004-03-07 at 10:20, Julian Foad wrote:
>        return svn_error_createf
>          (SVN_ERR_WC_OBSTRUCTED_UPDATE, tmp_err,
>           "Won't delete locally modified directory '%s'", path);
> +      /* ### ... leaking any errors that were above tmp_err in the chain. */

As it turns out, all errors in a chain are allocated from the same pool,
so it's impossible to leak just part of an error chain.

(Whether that's clear from the API documentation is another question.)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Removed dir in repos with local modifications result in strange behavior.

Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Josef Wolf <jw...@raven.inka.de> writes:
> 
>>    jw@raven:~/sandbox/misc> svn up
>>    U  notice
>>    subversion/libsvn_wc/update_editor.c:780: (apr_err=155000)
>>    svn: Won't delete locally modified directory ''
>>    subversion/libsvn_wc/adm_ops.c:1669: (apr_err=155012)
>>    svn: File 'boot.txt' has local modifications
>>
>>OK, I forgot about the local modifications and it is a good thing that
>>svn reminds me. But how come that the locally modified directory don't
>>have a name? 
> 
> It's a poor message, it means
> 
>    Won't delete locally modified sub-directory within directory '.'

I had a look to see if there is a quick fix; I couldn't see exactly what is going on but I did make two observations that don't fix it: a tidy-up and an observation that errors are leaking:

Index: subversion/libsvn_wc/update_editor.c
===================================================================
--- subversion/libsvn_wc/update_editor.c        (revision 8897)
+++ subversion/libsvn_wc/update_editor.c        (working copy)
@@ -773,13 +773,12 @@
   if (tmp_err)
     {
       /* Remove the LOGFILE (and eat up errors from this process). */
-      svn_error_t *err2 = svn_io_remove_file (logfile, pool);
-      if (err2)
-        svn_error_clear (err2);
+      svn_error_clear (svn_io_remove_file (logfile, pool));

       return svn_error_createf
         (SVN_ERR_WC_OBSTRUCTED_UPDATE, tmp_err,
          "Won't delete locally modified directory '%s'", path);
+      /* ### ... leaking any errors that were above tmp_err in the chain. */
     }

   return err;

I'm not going to commit that; I'm just pointing it out so that if somebody goes to that code to try to improve the error message they might also have a go at fixing the leak and/or tidying the error_clear.


> I do think we should consider changing update: when a locally modified
> item is encountered during delete, update should unversion, warn, and
> continue.  There should only be an error if the unversioned item left
> behind causes an obstruction to a later add.

It's probably worth repeating that thought in a thread of its own.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Removed dir in repos with local modifications result in strange behavior.

Posted by Philip Martin <ph...@codematters.co.uk>.
Josef Wolf <jw...@raven.inka.de> writes:

>     jw@raven:~/sandbox/misc> svn up
>     U  notice
>     subversion/libsvn_wc/update_editor.c:780: (apr_err=155000)
>     svn: Won't delete locally modified directory ''
>     subversion/libsvn_wc/adm_ops.c:1669: (apr_err=155012)
>     svn: File 'boot.txt' has local modifications
>
> OK, I forgot about the local modifications and it is a good thing that
> svn reminds me. But how come that the locally modified directory don't
> have a name? 

It's a poor message, it means

   Won't delete locally modified sub-directory within directory '.'

>     jw@raven:~/sandbox/misc> svn revert server/config/boot.txt
>     Reverted 'server/config/boot.txt'
>
> This was the only modification. So "svn up" should work now. But:
>
>     jw@raven:~/sandbox/misc> svn up
>     subversion/libsvn_wc/update_editor.c:780: (apr_err=155000)
>     svn: Won't delete locally modified directory ''
>     subversion/libsvn_wc/adm_ops.c:1878: (apr_err=155012)
>     svn: Left locally modified or unversioned files

That's a different error, it doesn't mention a file.  I think you have
an unversioned file or directory somewhere under server/config.

>     jw@raven:~/sandbox/misc> svn st
>     !      .
>     M      BUILD
>     ?      server/config
>     !      server
>
> Note that the server/config directory has a question mark as if it was never
> under svn control. But this just _can't_ be true because I just reverted
> a change in a file from this directory.

It is true, you ran "svn up" after the revert and it deleted
server/config and made it unversioned.

> Now I tried to revert the whole
> directory:
>
>     jw@raven:~/sandbox/misc> svn revert server/
>     jw@raven:~/sandbox/misc> svn st
>     !      .
>     M      BUILD
>     ?      server/config
>     !      server
>
> Ough! Still not enough? So revert the _current_ dir. (note that I should
> loose local modifications to the BUILD file here):

No, revert is non-recursive by default (read the docs)

>     jw@raven:~/sandbox/misc> svn revert .
>     jw@raven:~/sandbox/misc> svn st
>     !      .
>     M      BUILD
>     ?      server/config
>     !      server
>
> Ough?? BUILD is still modified? And the directory is still in a strange
> state?

It's not "strange" it's incomplete (read the docs)

> OK, try recursive.
>
>     jw@raven:~/sandbox/misc> svn -R revert .
>     jw@raven:~/sandbox/misc> svn st
>     !      .
>     M      BUILD
>     ?      server/config
>     !      server
>
> WTF? Nothing changed?!?

I cannot reproduce that, can you?

>     jw@raven:~/sandbox/misc> svn up
>     subversion/libsvn_wc/update_editor.c:780: (apr_err=155000)
>     svn: Won't delete locally modified directory ''
>     subversion/libsvn_wc/adm_ops.c:1878: (apr_err=155012)
>     svn: Left locally modified or unversioned files

You have an unversioned directory (server/config) in server.

> Not that I really expected that this would help...
>
>     jw@raven:~/sandbox/misc> svn up .
>     At revision 39.

It's not the explicit "." that makes the difference it's the repeated
updates.

- update attempts to delete server/config but fails because
  server/config contains an unversioned item.  server/config gets left
  as unversioned.  The update fails.

- update doesn't attempt to delete server/config as it's unversioned,
  it fails to delete server because server/config is unversioned.
  server gets left behind as unversioned.  The update fails.

- update doesn't attempt to delete server as it's unversioned.  The
  update suceeds.

What fun!

I do think we should consider changing update: when a locally modified
item is encountered during delete, update should unversion, warn, and
continue.  There should only be an error if the unversioned item left
behind causes an obstruction to a later add.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org