You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2012/10/12 16:05:14 UTC

Update that pulls a null delta

If an update pulls in a null delta --- eg, because it updates across two
revisions that revert each other --- then it should behave as though it
pulled nothing at all: output no 'U    filename' lines, and print "At
revision %ld".

Right?

[[[
Index: subversion/tests/cmdline/update_tests.py
===================================================================
--- subversion/tests/cmdline/update_tests.py	(revision 1397561)
+++ subversion/tests/cmdline/update_tests.py	(working copy)
@@ -5881,7 +5881,40 @@ def update_with_parents_and_exclude(sbox):
                                         '--parents',
                                         sbox.ospath('A/B'))
 
+@XFail()
+def null_delta(sbox):
+  "pulling a null delta not output"
 
+  sbox.build()
+  wc_dir = sbox.wc_dir
+
+  iota = sbox.ospath('iota')
+  iota_contents = open(iota).read()
+
+  # r2
+  open(iota, 'w').write('foo\n')
+  sbox.simple_commit()
+
+  # r3
+  open(iota, 'w').write(iota_contents)
+  sbox.simple_commit()
+    
+  # A no-op update should have the same output as one pulling a null change.
+  sbox.simple_update(revision=3)
+  exit_code, output2, errput = svntest.main.run_svn(None, 'update', '-r3', iota)
+  if exit_code or errput:
+    raise svntest.Failure("update from r3 failed: %r" % [exit_code, errput])
+
+  sbox.simple_update(revision=1)
+  exit_code, output3, errput = svntest.main.run_svn(None, 'update', '-r3', iota)
+  if exit_code or errput:
+    raise svntest.Failure("update from r1 failed: %r" % [exit_code, errput])
+
+  if output2 != output3:
+    raise svntest.Failure("Test failed: two no-op updates have different "
+                          "outputs:\n"
+			  "%r\n%r\n" % (output2, output3))
+
 #######################################################################
 # Run the tests
 
@@ -5957,6 +5990,7 @@ test_list = [ None,
               update_move_text_mod,
               update_nested_move_text_mod,
               update_with_parents_and_exclude,
+              null_delta,
              ]
 
 if __name__ == '__main__':
]]]

Re: Update that pulls a null delta

Posted by Alan Barrett <ap...@cequrux.com>.
On Sat, 13 Oct 2012, Daniel Shahaf wrote:
>>> If an update pulls in a null delta --- eg, because it updates across two
>>> revisions that revert each other --- then it should behave as though it
>>> pulled nothing at all: output no 'U    filename' lines, and print "At
>>> revision %ld".
>>>
>>> Right?
>>
>> As a user, I want to see the 'U    filename' report.
>
>Perhaps '     filename' would be more accurate?  That way the output is
>still clear that "Nothing happened".

Or 'u    filename' (lowercase u), for "updated but nothing really changed".

--apb (Alan Barrett)

Re: Update that pulls a null delta

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Sat, Oct 13, 2012 at 17:54:07 +0200:
> On Sat, Oct 13, 2012 at 05:02:56PM +0200, Daniel Shahaf wrote:
> > Alan Barrett wrote on Sat, Oct 13, 2012 at 15:16:00 +0200:
> > > On Fri, 12 Oct 2012, Daniel Shahaf wrote:
> > >> If an update pulls in a null delta --- eg, because it updates across two
> > >> revisions that revert each other --- then it should behave as though it
> > >> pulled nothing at all: output no 'U    filename' lines, and print "At
> > >> revision %ld".
> > >>
> > >> Right?
> > >
> > > As a user, I want to see the 'U    filename' report.
> > >
> > 
> > Perhaps '     filename' would be more accurate?  That way the output is
> > still clear that "Nothing happened".
> 
> In my opinion a null delta is an edge-case not worth special-casing.
> I understand academic interest in the question. But I wouldn't see
> much point in changing the UI for this.

It's not academic, I started this thread because I actually ran into
this case and the output confused me.

Re: Update that pulls a null delta

Posted by Stefan Sperling <st...@elego.de>.
On Sat, Oct 13, 2012 at 05:02:56PM +0200, Daniel Shahaf wrote:
> Alan Barrett wrote on Sat, Oct 13, 2012 at 15:16:00 +0200:
> > On Fri, 12 Oct 2012, Daniel Shahaf wrote:
> >> If an update pulls in a null delta --- eg, because it updates across two
> >> revisions that revert each other --- then it should behave as though it
> >> pulled nothing at all: output no 'U    filename' lines, and print "At
> >> revision %ld".
> >>
> >> Right?
> >
> > As a user, I want to see the 'U    filename' report.
> >
> 
> Perhaps '     filename' would be more accurate?  That way the output is
> still clear that "Nothing happened".

In my opinion a null delta is an edge-case not worth special-casing.
I understand academic interest in the question. But I wouldn't see
much point in changing the UI for this.

Re: Update that pulls a null delta

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Alan Barrett wrote on Sat, Oct 13, 2012 at 15:16:00 +0200:
> On Fri, 12 Oct 2012, Daniel Shahaf wrote:
>> If an update pulls in a null delta --- eg, because it updates across two
>> revisions that revert each other --- then it should behave as though it
>> pulled nothing at all: output no 'U    filename' lines, and print "At
>> revision %ld".
>>
>> Right?
>
> As a user, I want to see the 'U    filename' report.
>

Perhaps '     filename' would be more accurate?  That way the output is
still clear that "Nothing happened".

> However, if updating to an intermediate revision would have produced
> conflicts, then updating to the final revision (which undoes the
> changes) should not produce conflicts.
>
> --apb (Alan Barrett)

Re: Update that pulls a null delta

Posted by Alan Barrett <ap...@cequrux.com>.
On Fri, 12 Oct 2012, Daniel Shahaf wrote:
>If an update pulls in a null delta --- eg, because it updates across two
>revisions that revert each other --- then it should behave as though it
>pulled nothing at all: output no 'U    filename' lines, and print "At
>revision %ld".
>
>Right?

As a user, I want to see the 'U    filename' report.

However, if updating to an intermediate revision would have produced
conflicts, then updating to the final revision (which undoes the
changes) should not produce conflicts.

--apb (Alan Barrett)

RE: Update that pulls a null delta

Posted by Bob Archer <Bo...@amsi.com>.

> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: Friday, October 12, 2012 3:03 PM
> To: Daniel Shahaf
> Cc: dev@subversion.apache.org
> Subject: Re: Update that pulls a null delta
> 
> On 10/12/2012 10:05 AM, Daniel Shahaf wrote:
> > If an update pulls in a null delta --- eg, because it updates across
> > two revisions that revert each other --- then it should behave as though it
> > pulled nothing at all: output no 'U    filename' lines, and print "At
> > revision %ld".
> >
> > Right?
> 
> I could understand arguments both ways for this, and certainly Subversion
> distinguishes between "file's been changed between versions X and Y" and
> "file's content differs between versions X and Y".
> 
> Immediately prior to performing an update such as the one you describe, you'd
> want 'svn status -u' to show you that the remote version was modified and not
> obscure that fact simply because the delta is null -- this is an indication that any
> attempt to commit local mods to that file is doomed to an out-of-date failure.
> 
> Likewise, it *could* be confusing for folks who do attempt to commit such a
> locally modified file 'foo', get an out-of-date error on the commit, run 'svn
> update foo' to resolve that issue but then see no output at all.
> 
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development


Re: Update that pulls a null delta

Posted by "C. Michael Pilato" <cm...@collab.net>.
On 10/12/2012 10:05 AM, Daniel Shahaf wrote:
> If an update pulls in a null delta --- eg, because it updates across two
> revisions that revert each other --- then it should behave as though it
> pulled nothing at all: output no 'U    filename' lines, and print "At
> revision %ld".
> 
> Right?

I could understand arguments both ways for this, and certainly Subversion
distinguishes between "file's been changed between versions X and Y" and
"file's content differs between versions X and Y".

Immediately prior to performing an update such as the one you describe,
you'd want 'svn status -u' to show you that the remote version was modified
and not obscure that fact simply because the delta is null -- this is an
indication that any attempt to commit local mods to that file is doomed to
an out-of-date failure.

Likewise, it *could* be confusing for folks who do attempt to commit such a
locally modified file 'foo', get an out-of-date error on the commit, run
'svn update foo' to resolve that issue but then see no output at all.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development