"svn mv" after the fact??

["P.Marek" <pm...@users.sourceforge.net>]

It happens often to me that I do moves or renames and think about that just 
before commit.

I know that it's not that difficult to remember. But it happens often that 
some developer just do their work and it's left to me to check the changes 
in. So sometimes I only discover with "svn st" that things have been moved or 
renamed.

Trying to register this moving with svn results in a "unknown svn_node_kind" - 
presumably because the source does no longer exist. --force didn't help, 
either.

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




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: "svn mv" after the fact??

[kf...@collab.net]

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

Yah, in fact I thought we did this, with --force.  I guess not... want
to file an issue?  Might be Post-1.0, since there's such an easy
workaround, but then again it might be so bite-sized that someone can
just polish it off in an hour or two.  At least we won't forget about
it with an issue.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: "svn mv" after the fact??

["P.Marek" <pm...@users.sourceforge.net>]

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

Re: "svn mv" after the fact??

[Jack Repenning <jr...@collab.net>]

At 12:24 PM +0200 7/1/03, P.Marek wrote:
>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?

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?).


-- 
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org