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 14:49:53 2007