> Lets get this straight, we are talking about a working copy file or
> directory that has been removed from the physical file system but has
> not been scheduled for deletion in the working copy, correct?
yes.
> Now running svn_client_delete on such items should be possible, and
> for files it works. Directories do appear to have a problem.
>
> The rest is harder :)
>
> Calling svn_client_move for files should be possible, I guess it can
> reconstruct the file from the text-base. I'm not exactly sure how it
> should behave in Steve's case where the destination file already
> exists, at present if you try to move a file onto an existing file you
> get an "already exists" error, but Steve appears to want the operation
> to succeed. I don't think that should be the default behaviour but
> perhaps it could be enabled using the force flag. I assume it would
> use the existing file rather than replace it with the text-base, so
> perhaps force is not quite right, but I guess it would do.
>
> Calling svn_client_move on directories is a bit harder, as we cannot
> reconstruct the missing directory. I suppose we could add an entry
> and have it would show up as missing ("!" in status) but that doesn't
> seem useful for something that is scheduled for addition. Again, as I
> understand in Steve's case, the destination will already exist and I
> assume he doesn't want an "already exists" error. The difficulty here
> is that we don't know that the existing directory hierarchy looks
> anything like the missing one. Just assuming that it is the same
> sounds like it could be a problem, although perhaps it just fails
> gracefully if you try to commit it.
>
> The current behavior for "mv foo bar" where bar is an existing
> directory is "cp foo bar/foo && rm foo". Again this does not appear to
> be what Steve wants, he wants "bar" as the destination not "bar/foo".
>
> At present move is implemented in terms of copy + delete, so we
> probably need to make svn_client_copy work on these items as well.
> Also we need to consider how this will affect with the propsal to make
> move an atomic filesystem operation.
>
> Someone (Steve?) needs to write a complete requirement for this
> proposal, detailing what they should happen both if the target exists
> and does not exist. You need to consider whether the target is
> versioned or not as well.
>
> The next problem is that the missing directory is going to cause
> further problems, it may well prevent commit, and update and revert
> from running. The command line client gets really upset if a
> directory scheduled for deletion is missing.
>
> Steve, subversion is currently based on having a directory tree
> representing the deleted directory hierarchy. Without that tree your
> working copy is not complete. Issue 611 proposes moving the deleted
> hierarchy into the .svn area so that it is not visible in the working
> copy, but the tree will still exist.
I didn't wanted to cause so much work. I don't know the internals of
subversion
but this is what I think that subversion does (correct me please if I'm
totally wrong):
1. the client calls svn_client_move
2. subversion locks the required files
3. the file/dir in the filesystem is moved
4. the admin files are now updated to reflect the move
5. unlock of the files
6. the function returns
all I want is that if step 3 fails the function still tries to do
the rest. If the original file is needed then subversion could
check if the destination file is already there and then just use that.
Maybe the force flag is not very usefull for that so why not introduce
a flag "alreadydone" so that subversion knows that it should skip doing
the changes in the filesystem itself?
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 1 19:17:37 2002