> In an ideal world, Subversion would be perfectly mind-reading: the
> user could make a filesystem change with the OS, and svn could "follow
> in its footsteps" perfectly. But libsvn_wc simply isn't mature enough
> yet; CVS and SVN therefore both have an ongoing restriction that the
> svn client must be used to make tree-changes. Over time, it will be
> great to relax this restriction. But the truth is that to get what
> you want, it means a bunch of architectural redesign to libsvn_wc,
> which just can't be justified as a 1.0 priority.
Maybe I'm missing something here but I just can't see the problems
that feature would cause. To do a move/rename in a working copy
subversion makes some changes in the .svn directory to remember
that action for the next commit, then (or before?) does the move/rename
in the real filesystem. All I'm asking for is that the latter part (in the
real
filesystem) is _not_ done by subversion (it simply assumes that the client
itself does/did that).
> Does win32 explorer really only give you *post* change hooks? No
> *pre* change hooks? That sounds like a ridiculous flaw in the
> explorer API!
There's an API which could be used to allow/disallow moves/renames
of directories, but not files.
The API I'm using got documented last august ('cause of the lawsuit)
and only supports post change messages.
> You could do a workaround for now: if the user moves a file, have
> your post-change function simply move the file *back*, then run 'svn
> mv'.
Already had that coded. But the problem with that is that it takes too
much time if the file is very big.
But if that's the only solution then I will revert back to my previous
version.
Steve King
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 8 18:53:19 2003