Hi Ben :)
I'm working on the following revision 27110 that you committed (bug #503).
You're right, I should be more public and open-sourcy in my work :) I'll
give you update
as soon as I have something at hand. Thanx for the reponse!
//Freddie
On Nov 15, 2007 2:49 PM, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> Try looking at update tests 37 thru 39, guys. It demonstrates the
> feature. And to see the algorithm being used, look at
> libsvn_wc/update_editor.c:add_file_with_history.
>
> Freddie: I hope you're working on improving the existing solution in
> the latest trunk code, rather than planning to offer up a completely
> different solution out of the blue? That wouldn't be very...
> open-sourcey. :). Open source is inherently a social activity, and
> involves lots of discussion and collaboration. If you're working in
> an isolated cave, please come out of hiding and show us what you're
> doing!
>
>
> On 11/15/07, Freddie Albertsman <c03fan@cs.umu.se> wrote:
> > Hi Tor!
> >
> > I'm working on the copy-on-update problem; it works actually when the
> delete
> > happens after the add. I'm working on a solution that would always make
> the
> > delete happens at the very end.
> >
> > I haven't come across any example either that makes the scenario you
> > presented (copy on update) behave normally.
> >
> > //Freddie
> >
> > On Nov 15, 2007 1:48 PM, Tor Ringstad <torhr@pvv.org> wrote:
> >
> > > [Mark Phippard <markphip <at> gmail.com>]
> > > > I am not sure if this is predictable via filename. You could do:
> > > >
> > > > svn mv file2 afile2
> > > >
> > > > And see if that is different.
> > >
> > > I've experimented a bit, but I'm not able to construct any scenario
> > > where an add comes before the delete. In fact, it almost looks like
> > > *all* deletes always comes first, then *all* adds (for pure renames,
> > > that is).
> > >
> > > > Moving a file from a subdir into its parent should do it.
> > >
> > > Well, just sort of. I redid the test from my initial post, but instead
> > > of just plainly renaming the file, i moved it out of a subdir.
> > >
> > > Initial setup is a directory "dir" with a single empty file "file",
> > > and two up-to-date working copies.
> > >
> > > WC2:
> > >
> > > # Move file
> > >
> > > % svn mv dir/file .
> > > A file
> > > D dir/file
> > > % svn commit -m "moved"
> > > Deleting dir/file
> > > Adding file
> > > Committed revision 128.
> > >
> > > WC1:
> > >
> > > # Modify local file, get move via update
> > >
> > > % echo foobar >> dir/file
> > > % svn st
> > > M dir/file
> > > % svn up
> > > A file # note #1
> > > D dir/file
> > > Updated to revision 128.
> > > % svn st
> > > ? dir/file
> > > % cat file
> > > <empty>
> > > % cat dir/file
> > > foobar
> > >
> > > Now the add actually comes before the delete (note #1), but the local
> > > modifications are still "lost" in the now unversioned dir/file.
> > >
> > > So I'm kind of back to my initial question; are there actually any
> > > examples of the "Improved copy-handling during updates" functionality
> > > that is described in the release note:
> > >
> > >
> http://subversion.tigris.org/svn_1.5_releasenotes.html#leverage-copyfrom
> > >
> > > Is this text perhaps promising a bit much? I have to say I got high
> > > expectations after reading it, and I'm sure a lot of others will as
> > > well.
> > >
> > >
> > > - Tor Ringstad -
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > > For additional commands, e-mail: dev-help@subversion.tigris.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Received on Thu Nov 15 15:02:35 2007