Re: svn stat on new files

Following on from this, I thought I would experiment with resolving a
conflict between two simultaneously-added files.

In the repository that lost the race to commit the file:

    % svn stat
    A added

(I've marked-for-add but not committed; somebody else has already
added & committed this file.)

    % svn up
    svn: Obstructed update
    svn: failed to add file 'added': object of the same name already exists

OK, fine...

    % mv added added.new

I suspect the average user will respond to "obstructed update" by
moving the file to a temporary name as I did. This seems to work OK
in CVS.

    % svn up
    A added

OK, so "added" was added by someone else, and was put into my wc when
I updated. So far, so good.

    % svn stat
    A added
    ? added.new

This seems strange... Since the file "added" in this wc came from
somebody else's commit, it ought to be marked uptodate, rather than
'A'.

Perhaps I should have svn rm'd my "added" file before I tried to
update. On the other hand, if Subversion has allowed the update to
occur and has put the new file into my wc, then it ought to no longer
record this file as locally added.

Things now seem a bit broken...

    % svn commit added
    svn: Invalid argument
    svn: Commit failed (details follow):
    svn: failure during string recoding
    % svn commit -m 'foo' added
    Adding added
    svn: Item already exists in filesystem
    svn: Commit failed (details follow):
    svn: file already exists: filesystem `/var/subversion/hello/db', transaction `z', path `/trunk/added'

Having screwed things up, perhaps reverting will save me?

    % svn revert added
    Reverted added

Sounds good...

    % svn stat -uv
    10 10 mbp .
    ? added
    ? added.new
    Head revision: 10

It looks like svn thought that because the file was locally-added, the
right way to revert was to remove that flag? At any rate, it didn't
get back to uptodate.

I can think of two possibly better approaches:

1- A conflict between a locally and remotely added file must be
cleared by "svn rm" (or "svn revert"?) before the update can proceed.
Just removing the wc is not enough. The "obstructed update" message
ought to say so.

or, 2- When a file is marked as locally added, but there is no wc,
then the update can proceed and the file becomes marked as uptodate.
This is perhaps less clear, but more similar to CVS.

Thanks,

-- 
Martin 
Like washing up, unit testing is easy if you do it as you go along.
If you leave it for three months, it looks very intimidating.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org