Re: Rename problem

I actually think that tracking rename info in wc metadata might be
useful for the *opposite* situation to the one Freddie described: if
you've done "svn mv a b" in your working copy and you pull down an
update that tries to modify a...

--dave

On 10/25/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> Hi Freddie,
>
> You're welcome to write your prototype, but at this point, it would be
> solving a problem that's already been solved. (That is, assuming
> we're talking about the use-case you described.) The server now sends
> the rename information the client during an update, and the client
> then tries to hunt down the original file in the working copy as
> something to copy. I can't see why it would be useful to persist this
> rename information in working-copy metadata. Maybe you have other
> use-cases in mind?
>
>
> On 10/25/07, Freddie A. <freddie.alberts@gmail.com> wrote:
> > Hej Ben!
> >
> > Thank you for the fast response! Sorry I couldn't reply sooner I was a bit
> > busy.
> > Well, I would really like to help out with renaming. At the moment I'm
> > working on a prototype that would solve the scenario that I presented
> > earlier, when I'm done, I will tell you about the results and present the
> > prototype so the community can have a look at it and perhaps adapt it. Even
> > when I'm finished with my thesis, I would still like to help out since I'm
> > getting more and more experience with the "subversion code".
> >
> > Yours,
> > Freddie Albertsman
> >
> >
> > On 10/16/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> > > Subversion 1.5 already (partially) solves this problem. It's using
> > > infrastructure that has been in subversion client/server since day 1,
> > > but was never taken advantage of until recently.
> > >
> > > Specifically, when the server transmits an 'update' to the client, it
> > > sends (1) a delete command and (2) a copy command. What's new in svn
> > > 1.5 is that the copy command now includes the "copy source" path. The
> > > client attempts to find the copy source in the working copy (as a
> > > pre-existing versioned file), rather than the server blindly pushing
> > > the file at the client. This means, in your example, the client would
> > > copy the locally-modified foo.c to bar.c rather than receiving an
> > > older version of bar.c.
> > >
> > > That's the ideal scenario, of course. The snag in this system is that
> > > there's no way to prevent the server from doing the 'delete' before
> > > the 'copy'; if this happens, then the client can't find the
> > > locally-modified file to copy. The plan is to fix this problem in svn
> > > 1.6, by having the client track deletions during an update (perhaps
> > > not really doing the deletions until the very end of the update, thus
> > > making sure they're available for the copy.)
> > >
> > > For more info on this, see issue 503 in the bugtracker. It would be
> > > great if you wanted to help out.
> > >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org