Re: [PATCH] Copy/move-handling on update in 1.5

On Mon, Jan 28, 2008 at 10:08:34PM +0000, Julian Foad wrote:
> (Just looking back through my mail...)
>
> Freddie/David/anyone,
>
> Did this ever go anywhere? Is there still a problem that needs solving?
>
> - Julian

I'd like to see the patch in unidiff.

Thanks for bumping this Julian. The problem quoted below sounds exactly
like one of the problems we are working on on the tree-conflicts branch,
but this thread had escaped my attention so far.

More precisely it's actually tree conflict use case 3.
See notes/tree-conflicts/use-cases.txt on the subversion trunk:
http://svn.collab.net/viewvc/svn/trunk/notes/tree-conflicts/use-cases.txt?view=markup

>> On Dec 6, 2007 2:10 AM, Freddie Albertsman <c03fan_at_cs.umu.se> wrote:
>> > Hey Guys!
>> > I have one question concerning concerning the "update ignores added
>> > files/dirs":
>> >
>> > Consider the following scenario:
>> >
>> > repos. contains /trunk/foo
>> >
>> > #user A
>> > rename foo -> bar
>> > echo "HELLO BAR" > bar
>> >
>> > #user B
>> > rename foo -> baz
>> > echo "HELLO BAZ" > baz
>> > commit
>> >
>> > #user A
>> > update
>> >
>> > Now if the "newly" added file, bar, in user A's wc is ignored then the
>> > server will throw a new file (baz coming from B). When user A commits after
>> > updating, the file "bar" will be added as well and we end up with two files
>> > in the repository where it should have been only one file.

With the current code on the tree-conflicts branch, user A should
get a conflict upon trying to commit from the working copy after
the update:

Note that the file "bar" will still be added to A's working copy
nonetheless, but because the commit is blocked until A has made
a concious decision about what to do with the files, the problem
is effectively stopped before it reaches the repository.

Can you try this branch and check if it provides an adequate solution
to the problem you are describing? To get the source, run:

    svn co https://svn.collab.net/repos/svn/branches/tree-conflicts

>> > I think that
>> > files which are added AND copied should not be ignored.
>> > What do you think guys?

The file user A added with history is not being ignored. What is being
ignored is that the file baz coming down in the update has common ancestry
with the newly added file bar in A's working copy, and that the delete that
occurs on foo in A's working copy upon update is related to a rename operation
carried out by user B.

Because of the way the update editor works you only get to look at
a single file the update pushes to the working copy for a given add or
delete operation. So establishing relationships between files across the
whole working copy during an update operation is hard.

And with the current rename implementation (or rather, lack of)
there seems to be no reliable way to retroactively tell apart deletes
that occurred because of "svn move" from deletes that occurred because
of "svn delete".

See notes/tree-conflicts/detection.txt on the subversion trunk for a more
detailed explanation of these issues:
http://svn.collab.net/viewvc/svn/trunk/notes/tree-conflicts/detection.txt?view=markup

If you have any ideas about solving this problem a better way
I'd love to hear them.

Thanks,

-- 
Stefan Sperling <stsp_at_elego.de>                 Software Developer
elego Software Solutions GmbH                            HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12        Tel:  +49 30 23 45 86 96 
13355 Berlin                              Fax:  +49 30 23 45 86 95
http://www.elego.de                 Geschaeftsfuehrer: Olaf Wagner