moving files in a smarter way

[hilz <hs...@hotmail.com>]

Hi,
I asked this question on the tortoisesvn list but it seems is it a svn 
issue, so i will ask again here.

If i move versioned files on one machine from one directory to another 
and commit, everything works fine...
Now on another machine, when i do an update, the files are fetched again 
from the server. Why isn't svn smart enough to know that these files 
already exist on that machine in a different location, and just move 
them locally to the new location without actually fetching them again 
from server?

thanks

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

Re: moving files in a smarter way

[Talden <ta...@gmail.com>]

> > Because a move is - currently - modelled as a Delete + Add, which is
> > what the new client is receiving. Because of the Add, it also needs
> > the new content.

> I don't entirely buy that explanation, because it's not just an add,
> it's a *copy*, and the WC already contains the "copyfrom" source
> (or whatever it's called). [*]
>
> I don't think it should be necessary for the holy grail of
> "true renames" to be obtained before a simple copy can
> be implemented efficiently.

I'd have thought a copy would occur and then the delete but if that
isn't the case then I can understand why the client doesn't make this
optimisation now as it would need to either move all such files to a
holding pen in case a copy is needed or it would need to look forward
in the transaction.

I don't know how far away atomic moves are but they will open up a
whole bunch more performance opportunities when they are done.  I
originally thought they were being treated as compulsory for the
merge-tracking to be completed but I think I saw mention that this is
not the case... I hope the the nice people doing the work have time to
do it soon because merge-tracking and atomic moves are serious steps
forward for Subversion.

Is there a way of getting a '1.5 road-map' report from issue-tracking?
 I'm aware 1.5 is a ways off given that 1.4 has just been released but
it'd be nice to know what's on the horizon (even if those features
might change as development progresses).

--
Talden

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

Re: moving files in a smarter way

[Ed Price <ed...@gmail.com>]

> > If i move versioned files on one machine from one directory to another
> > and commit, everything works fine...
> > Now on another machine, when i do an update, the files are fetched again
> > from the server. Why isn't svn smart enough to know that these files
> > already exist on that machine in a different location, and just move
> > them locally to the new location without actually fetching them again
> > from server?
>
> Because a move is - currently - modelled as a Delete + Add, which is
> what the new client is receiving. Because of the Add, it also needs
> the new content.

I don't entirely buy that explanation, because it's not just an add,
it's a *copy*, and the WC already contains the "copyfrom" source
(or whatever it's called). [*]

I don't think it should be necessary for the holy grail of
"true renames" to be obtained before a simple copy can
be implemented efficiently.

Resolving this issue would be very nice for people who
work with large files (and/or slow/glitchy networks).

(I experience the inefficiency all the time, using svn
to store photos and videos, which I frequently move
and rename.)

-Ed

PS [*] ok ok maybe if the delete gets run first that spoils it,
but still I'd hope that could be addressed without requiring
"true rename" support.

On 10/10/06, Erik Huelsmann <eh...@gmail.com> wrote:
> On 10/10/06, hilz <hs...@hotmail.com> wrote:
> > Hi,
> > I asked this question on the tortoisesvn list but it seems is it a svn
> > issue, so i will ask again here.
> >
> > If i move versioned files on one machine from one directory to another
> > and commit, everything works fine...
> > Now on another machine, when i do an update, the files are fetched again
> > from the server. Why isn't svn smart enough to know that these files
> > already exist on that machine in a different location, and just move
> > them locally to the new location without actually fetching them again
> > from server?
>
> Because a move is - currently - modelled as a Delete + Add, which is
> what the new client is receiving. Because of the Add, it also needs
> the new content.
>
> This is currently being worked on ('Implement true renames'), but it's
> a multi-stage project which needs a lot of work before effects can be
> seen on the client side.
>
> HTH,
>
> Erik.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

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

Re: moving files in a smarter way

[Erik Huelsmann <eh...@gmail.com>]

On 10/10/06, hilz <hs...@hotmail.com> wrote:
> Hi,
> I asked this question on the tortoisesvn list but it seems is it a svn
> issue, so i will ask again here.
>
> If i move versioned files on one machine from one directory to another
> and commit, everything works fine...
> Now on another machine, when i do an update, the files are fetched again
> from the server. Why isn't svn smart enough to know that these files
> already exist on that machine in a different location, and just move
> them locally to the new location without actually fetching them again
> from server?

Because a move is - currently - modelled as a Delete + Add, which is
what the new client is receiving. Because of the Add, it also needs
the new content.

This is currently being worked on ('Implement true renames'), but it's
a multi-stage project which needs a lot of work before effects can be
seen on the client side.

HTH,

Erik.

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