You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Freddie Albertsman <c0...@cs.umu.se> on 2007/12/06 10:10:31 UTC
Re: Copy/move-handling on update in 1.5
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. I think that
files which are added AND copied should not be ignored.
What do you think guys?
One more thing, I think I might have solved an issue about copying on
updating described in this scenario:
1.User A checks out /repos/trunk/proj containing foo.c
2.User B checks out /repos/trunk/proj containing foo.c
3.User A makes changes to foo.c
4.User B renames foo.c to bar.c and makes some changes
5.User B commits
6.User A updates
Ben said that this scenario would if the deletetion of foo happens AFTER the
add of bar (when A does an update). Well, now it the deletion of foo happens
after the addition of bar if bar has a copyfrom that is (foo). So when at
step 6, A does an update, then the bar is merged with foo and then bar is
added and foo deleted.
PS
Ben, I'm coming out of the cave now! :-)
On Nov 15, 2007 8:04 PM, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On Nov 15, 2007 11:54 AM, Tor Ringstad <to...@pvv.org> wrote:
>
> > So the bottom line still seems to be that nobody has ever seen a
> > scenario similar to that described in the release note, that is,
> > involving a move, where the local changes are handled correctly...
>
> Look at the update_copied_from_replaced_and_changed test... it
> involves 2 moves.
>
>
> >
> > (Nice poem on r26957, by the way :)
>
> Oh noes, I've been discovered!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: [PATCH] Copy/move-handling on update in 1.5
Posted by Stefan Sperling <st...@elego.de>.
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 <c0...@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 <st...@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
Re: [PATCH] Copy/move-handling on update in 1.5
Posted by Julian Foad <ju...@btopenworld.com>.
(Just looking back through my mail...)
Freddie/David/anyone,
Did this ever go anywhere? Is there still a problem that needs solving?
- Julian
Freddie Albertsman wrote:
>
> Hey David!
>
> Yes, I have a patch for this, it should be applied to
> ../libsvn_repos/reporter.c.
>
> There is a function (check_order) that checks if the entry is "special",
> which means if it is be merged with a newer version with a different
> names. In which case it will be deleted at the end. It works on linux
> but i haven't tested in windows, but it should work there too. Sorry i
> didn't send this before i was sick+busy.
>
> Yours,
> Freddie
>
>
> On Dec 10, 2007 7:26 PM, David Glasser < glasser@davidglasser.net
> <ma...@davidglasser.net>> wrote:
>
> On Dec 6, 2007 2:10 AM, Freddie Albertsman <c03fan@cs.umu.se
> <ma...@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. I
> think that
> > files which are added AND copied should not be ignored.
> > What do you think guys?
>
> This point is interesting, but I don't think it's related to the new
> 1.5 feature; the behavior you point out occurs in 1.4 as well.
>
> > One more thing, I think I might have solved an issue about copying on
> > updating described in this scenario:
> > 1.User A checks out /repos/trunk/proj containing foo.c
> > 2.User B checks out /repos/trunk/proj containing foo.c
> > 3.User A makes changes to foo.c
> > 4.User B renames foo.c to bar.c and makes some changes
> > 5.User B commits
> > 6.User A updates
> >
> > Ben said that this scenario would if the deletetion of foo
> happens AFTER
> > the add of bar (when A does an update). Well, now it the deletion
> of foo
> > happens after the addition of bar if bar has a copyfrom that is
> (foo). So
> > when at step 6, A does an update, then the bar is merged with foo
> and then
> > bar is added and foo deleted.
>
> I can't follow if you're saying that you have a patch that
> implements this?
>
> --dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] Copy/move-handling on update in 1.5
Posted by Freddie Albertsman <c0...@cs.umu.se>.
Hey David!
Yes, I have a patch for this, it should be applied to
../libsvn_repos/reporter.c.
There is a function (check_order) that checks if the entry is "special",
which means if it is be merged with a newer version with a different names.
In which case it will be deleted at the end. It works on linux but i haven't
tested in windows, but it should work there too. Sorry i didn't send this
before i was sick+busy.
Yours,
Freddie
On Dec 10, 2007 7:26 PM, David Glasser <gl...@davidglasser.net> wrote:
> On Dec 6, 2007 2:10 AM, Freddie Albertsman <c0...@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. I think that
> > files which are added AND copied should not be ignored.
> > What do you think guys?
>
> This point is interesting, but I don't think it's related to the new
> 1.5 feature; the behavior you point out occurs in 1.4 as well.
>
> > One more thing, I think I might have solved an issue about copying on
> > updating described in this scenario:
> > 1.User A checks out /repos/trunk/proj containing foo.c
> > 2.User B checks out /repos/trunk/proj containing foo.c
> > 3.User A makes changes to foo.c
> > 4.User B renames foo.c to bar.c and makes some changes
> > 5.User B commits
> > 6.User A updates
> >
> > Ben said that this scenario would if the deletetion of foo happens
> AFTER
> > the add of bar (when A does an update). Well, now it the deletion of foo
> > happens after the addition of bar if bar has a copyfrom that is (foo).
> So
> > when at step 6, A does an update, then the bar is merged with foo and
> then
> > bar is added and foo deleted.
>
> I can't follow if you're saying that you have a patch that implements
> this?
>
> --dave
>
> --
> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
>
Re: Copy/move-handling on update in 1.5
Posted by David Glasser <gl...@davidglasser.net>.
On Dec 6, 2007 2:10 AM, Freddie Albertsman <c0...@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. I think that
> files which are added AND copied should not be ignored.
> What do you think guys?
This point is interesting, but I don't think it's related to the new
1.5 feature; the behavior you point out occurs in 1.4 as well.
> One more thing, I think I might have solved an issue about copying on
> updating described in this scenario:
> 1.User A checks out /repos/trunk/proj containing foo.c
> 2.User B checks out /repos/trunk/proj containing foo.c
> 3.User A makes changes to foo.c
> 4.User B renames foo.c to bar.c and makes some changes
> 5.User B commits
> 6.User A updates
>
> Ben said that this scenario would if the deletetion of foo happens AFTER
> the add of bar (when A does an update). Well, now it the deletion of foo
> happens after the addition of bar if bar has a copyfrom that is (foo). So
> when at step 6, A does an update, then the bar is merged with foo and then
> bar is added and foo deleted.
I can't follow if you're saying that you have a patch that implements this?
--dave
--
David Glasser | glasser@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