Here's a situation I've run into while coding. Theoretically, I'm
kind of annoyed by what seems like the only reasonable approach.
Maybe other people have ideas about what to do.
The editor functions add_file() and add_directory() have special extra
arguments which (up to now) have always been ignored -- by both
editor-drivers and editor-implementors. These are the 'copyfrom'
arguments. In particular, the call:
add_file ("foo", parent_baton, "/dir1/dir2/bar", 33)
Means "I'm adding a new file foo to the parent, but I want it to be a
*copy* of /dir1/dir2/bar in revision 33.". The Subversion filesystem
knows how to make copies; 'foo' will have a totally new node-rev-id,
but still contain an internal pointer indicating that it was copied
from another node-rev-id. History is preserved.
So, as I implement the 'svn cp' command, I discover that the client is
actually going to be sending these copyfrom args to the
commit-editor for the first time. Fine... so what's the problem?
The problem is that in *theory*, the copyfrom_path should be an
absolute filesystem path. That's all the editor is supposed to deal
with: paths within some filesystem. But the client doesn't have the
path! Why? Because we store nothing but full URLs in the
.svn/entries file. When looking at the URL, the client libraries are
unable to figure out where the repository ends and where the
filesystem path begins.
[This hearkens back to an old argument, about a year ago, whereby it
was being debated whether we should store the repository and fs path
separately or not. I wonder if we made a wrong choice. Sigh.]
Anyway, the "practical" thing to do is just pass the full URL to
add_file and add_directory... and then let the RA layer do the
splitting before calling svn_fs_copy(). But this bugs me, because we
really shouldn't be sending URLs into editors. Editors have remanined
relatively abstract up till now. I'd hate to ruin this.
Ideas?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:45 2006