> Consider a versioned directory foo, that is missing from the working
> copy (it's been non-svn moved). Now how does
>
> svn mv foo bar
>
> behave given that bar exists? (I'm using the command line client here
> but the same arguments apply to the svn_client_move function.) At
> present a move where bar exists creates bar/foo, obviously you want to
> change that. When is bar/foo the real target and when is bar the real
> target?
ok, got your point. I try to make things clearer for what I have in mind:
For what I need svn mv should simply assume that
the existing bar is the already moved foo. So no need to recreate foo
from the text-base. The client has to make sure that bar really *is* the
already moved foo.
> Consider some possibilities
>
> - bar is unversioned
> This is probably an error.
In my case bar is always unversioned since it has been non-svn-moved
from foo.
> - bar is versioned and is already part of the same working copy as foo
> Here bar/foo is the real target, it is probably an error if foo
> doesn't exist.
if bar is versioned then the non-svn-move must have overwritten an
already existing versioned bar. This is definitely an error.
> - bar is versioned and is not a working copy base
> This is probably an error.
I don't understand this. How could that get happen? I thought that
a versioned item *has* to have a text-base?
> - bar is versioned and is a working copy base and the bar URL/GUID
> differ from the foo URL/GUID
> This is probably an error
same as above. For what I need it won't happen at all that bar is versioned.
Or if it happens then it must be an error!
> The last time this came up I asked[1] those interested in the feature
> to provide a complete description of the required behaviour; no such
> description appeared.
Sorry for that.
> As I have shown above, the number of cases that need to be considered
> is non-trivial. I haven't determined how they all should work, I
> don't think I have even identified them all.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 8 21:36:52 2003