[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "svn mv" after the fact??

From: P.Marek <pmarek_at_users.sourceforge.net>
Date: 2003-07-02 07:25:37 CEST

> >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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.