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
Received on Thu Oct 25 16:19:58 2007