> >So I have to
> >1) move the files back
> >2) do a "svn mv"
> >which, as I know, could be automated away with a script, but nonetheless
> > ...
> >
> >How about using the special-case in which
> >a) source does no longer exist and
> >b) target does exist
> >just doing the bookkeeping without doing the move or showing an error??
>
> I'm not sure, but I think what you mean here is that a move is done
> in the plain file system (Unix "mv" or something like that), and you
> think "svn commit" should figure out which new file matches which
> missing old file Is that it?
No. As you say below, that wouldn't be reliable.
> I do not understand how we could make this intuitive leap. There are
> some heuristics we could apply (such as tracking the inode number),
> but they're nonportable (Windows? Inodes?) and not very reliable
> (some editors change the inode when saving a change). There are also
> edge cases (should we ignore every file named <oldname>.save? How
> about <oldname>.bak? What if the user wanted to add *.save to the
> repository? How widely throughout the WC should we search for the
> moved file?).
No. All I wanted was a way to tell svn "this file has moved from it's old
location. It's not there anymore, it's now here." But svn complains about an
unknown svn_node_kind, as I said.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 2 07:26:38 2003