cmpilato@collab.net writes:
> "Ich Selbst" <ichselbst@gmx.ch> writes:
>
> > I'm currently working on a shell integration of subversion and I ran into a
> > problem which I can only solve if some functions of subversion are enhanced:
> >
> > I can catch an event whenever the user renames or deletes an file/folder,
> > ut only AFTER the operation has completed. If I then call svn_client_move()
> > or svn_client_delete() to sync with subversion those functions just return
> > with an error that the file is not there (anymore).
> >
> > Could those functions not just ignore the fact that the file isn't
> > there and only perform the function? (in the subversion files in
> > .svn).
>
> I think this is reasonable. After all, the working file need not be
> present to do the kinds of administration work required for these
> operations.
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?
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.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 1 18:48:55 2002