On Fri, Mar 16, 2012 at 07:58:18AM -0400, Greg Stein wrote:
> On Mar 16, 2012 5:30 AM, <philip_at_apache.org> wrote:
> >...
> > +++ subversion/trunk/subversion/tests/cmdline/update_tests.py Fri Mar 16
> 09:29:49 2012
> > @@ -5696,6 +5696,101 @@ def update_moved_dir_file_move(sbox):
> > None, None, None,
> > None, None, 1)
> >
> > +@XFail()
> > +def update_move_text_mod(sbox):
> > + "text mod to moved files"
> > +
> > + sbox.build()
> > + wc_dir = sbox.wc_dir
> > + svntest.main.file_append(sbox.ospath('A/B/lambda'), "modified\n")
> > + svntest.main.file_append(sbox.ospath('A/B/E/beta'), "modified\n")
> > + sbox.simple_commit()
> > + sbox.simple_update(revision=1)
> > +
> > + sbox.simple_move("A/B/E", "A/E2")
> > + sbox.simple_move("A/B/lambda", "A/lambda2")
> > +
> > + expected_status = svntest.actions.get_virginal_state(wc_dir, 1)
> > + expected_status.tweak('A/B/E', 'A/B/E/alpha', 'A/B/E/beta',
> 'A/B/lambda',
> > + status='D ')
> > + expected_status.add({
> > + 'A/E2' : Item(status='A ', copied='+', wc_rev='-'),
> > + 'A/E2/alpha' : Item(status=' ', copied='+', wc_rev='-'),
> > + 'A/E2/beta' : Item(status=' ', copied='+', wc_rev='-'),
> > + 'A/lambda2' : Item(status='A ', copied='+', wc_rev='-'),
> > + })
> > +
> > + svntest.actions.run_and_verify_status(wc_dir, expected_status)
> > +
> > + expected_output = svntest.wc.State(wc_dir, {
> > + 'A/lambda2' : Item(status='U '),
> > + 'A/E2/beta' : Item(status='U '),
> > + })
>
> The above output for an 'svn update ' implies that the incoming edits will
> be applied to the moved files.
Yes, finally!!!
> I think that is wrong. I believe we should
> mark a conflict: incoming edit vs local move.
IMO you'd really want text conflicts in this case, not a tree conflict.
> The default resolution would
> be to apply, but I really do not believe we should silently update like
> this.
>
> Consider where I took some code that did X+Y and moved it to a new
> location, for use there (but not yet committed). Somebody else edits the
> code to remove Y, and commits.
>
> If I update, then the code I moved *changes* on me. I grabbed the code
> expecting X+Y. The removal of Y may have made sense in the old location,
> but not the new location.
You *moved* the file to "grab the code". A moved file is still the same
"container" (for lack of a better term), and changes destined for this
container should follow the move.
Why didn't you copy the file that contains the code you want to base
your changes on? If you don't care about keeping the "same container"
semantics, you should copy. And maybe even delete the source if you
like. That will still give you a tree conflict when the update brings
in changes for the deleted file.
Makes sense?
BTW, there are examples out there that you'd probably dislike even more :)
Mercurial will apply incoming changes to any local copy of a file
("local" here is of course a local branch, and the "update" is a "merge"
in hg terms). So if you made N copies of the same file, all those N files
get the incoming edits applied to them. I suppose that's something I could
get used to, but I prefer svn to make a distinction between copies and moves.
In our model, copies are branches, so if you wanted to apply changes to
copies you'd merge them.
Received on 2012-03-16 13:32:55 CET