> On Mon, May 23, 2011 at 3:07 PM, Konstantin Kolinko
> <knst.kolinko_at_gmail.com> wrote:
> > 2011/5/23 Mark Phippard <markphip_at_gmail.com>:
> >> On Mon, May 23, 2011 at 2:24 PM, Daniel Shahaf
> <d.s_at_daniel.shahaf.name> wrote:
> >>> Bob Archer wrote on Mon, May 23, 2011 at 13:54:59 -0400:
> >>>> I can't imagine that this would need to move the file over the
> network
> >>>> since it all happens server side. Although, I guess when you
> do an
> >>>> update it might bring the file down again rather than doing a
> local
> >>>> move/rename.
> >>>
> >>> update used to rely on copyfrom information to fetch just the
> delta for
> >>> moves/copies it had already had the base for, but we removed
> that
> >>> feature recently for other reasons.
> >>>
> >>> (I hope other can fill in the details --- such as why we
> removed it and
> >>> what releases will be affected --- I don't remember them
> offhand ): )
> >>
> >> I think Bob is just saying that if you move a file via its URL
> that
> >> nothing needs to transfer over the network. He acknowledges
> that it
> >> "might" when you do update again. I would note that if you move
> a
> >> file locally, it also does not have to send it over the network
> when
> >> you perform the commit. So it is actually probably cheaper to
> do it
> >> locally than on the server if you only have one working copy.
> >>
> >> The feature removed in 1.7 was that on update SVN could
> sometimes move
> >> a file locally rather than download it again. It was removed
> because
> >> due to the way SVN editor drives work, the feature only worked
> in
> >> certain situations (when the copy was sent to the client before
> the
> >> delete) and apparently the feature was just complicating the
> working
> >> copy code for what amounted to a hack with small benefits.
> If/when
> >> SVN grows a true rename feature it would have to be implemented
> >> properly.
> >>
> >
> > Ed,
> >
> > In svn 1.7 there is pristine storage area in the working copy,
> where
> > all present files are stored by their checksums. If I understand
> this
> > pristine storage correctly, if you move a file remotely on the
> server
> > (svn mv URL URL) then when you update your working copy and both
> old
> > and new paths are in the same working copy, Subversion will find
> the
> > file in its pristine storage and won't re-download it over
> network. If
> > what I wrote is true (I have not verified whether this actually
> works
> > this way, but I have some hopes),
>
> AFAIK, this sort of feature was not in scope for 1.7, but it is
> exactly the sort of feature that the WC rewrite will enable for
> future
> versions. Especially imagine some future version that lets you
> share
> a single pristine store across all your WC's. You could checkout
> trunk twice and the second one would not even need to transfer any
> files from the server.
Nice but isn't a pristine = base? how would this work if the two working copies had different BASE revisions?
1.7 should be able to locally move a file, but unfortunately even 1.7.0 isn't going to have a "moved" action is it? It will still look like a delete/add to the client?
BOb
Received on 2011-05-23 21:30:00 CEST