You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Marcus Comstedt <ma...@mc.pp.se> on 2002/01/23 22:16:43 UTC
redundant "conflicts"
Hm, I've been noticing a rather annoying thing about the update
functionality:
If my working copy is being updated to a new revision, and that
revision contains changes that are already present in my working copy
(as would be the case if I had sent in a patch, for example :), then
this is detected as a conflict, with the .rej file containing a no-op
transformation. cvs is not that stupid, so neither should svn be.
This would probably not be a very high-priority concern, but I didn't
see anything about it in the issue database, so I wanted to make sure
it wasn't overlooked completely. :-)
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: redundant "conflicts"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> I'd just like to put a stake in the ground: regression tests are nice, but I
> don't think we should impose them on our volunteers. There are enough bars
> for people to climb to be able to contribute... let's not add more.
We haven't been requiring them of anyone, we've just been strongly
encouraging them. I don't believe anyone's ever said "This patch must
come with a regression test or we won't consider it."
We should continue to encourage them, IMHO. They've caught lots of
problems already, and many people have found that writing them is not
as difficult as it looked.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: redundant "conflicts"
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jan 23, 2002 at 04:47:01PM -0600, Ben Collins-Sussman wrote:
>...
> Hey, see if it works! Try it out by adding this flag to our
> invocations of 'patch' in libsvn_wc/get_editor.c:close_file(). If it
> works, that's great. Give us a regression test, too. :-)
I'd just like to put a stake in the ground: regression tests are nice, but I
don't think we should impose them on our volunteers. There are enough bars
for people to climb to be able to contribute... let's not add more.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: redundant "conflicts"
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jan 23, 2002 at 05:00:21PM -0600, Ben Collins-Sussman wrote:
> Marcus Comstedt <ma...@mc.pp.se> writes:
>
> > > works, that's great. Give us a regression test, too. :-)
> >
> > Won't that require me to do battle with a Python? :-P
> >
>
> Well, gee, it's an opportunity to learn our testing API --if you don't
> want to copy/paste/hack one of the tests in update-tests.py, then I'll
> volunteer to write the test myself.
>
> This is assuming that -N fixes the problem, of course.
well, even if -N doesn't fix it, having a regression test for when we
do fix it is always a good thing.
-garrett
--
garrett rooney Unix was not designed to stop you from
rooneg@electricjellyfish.net doing stupid things, because that would
http://electricjellyfish.net/ stop you from doing clever things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: redundant "conflicts"
Posted by Ben Collins-Sussman <su...@collab.net>.
Marcus Comstedt <ma...@mc.pp.se> writes:
> > works, that's great. Give us a regression test, too. :-)
>
> Won't that require me to do battle with a Python? :-P
>
Well, gee, it's an opportunity to learn our testing API --if you don't
want to copy/paste/hack one of the tests in update-tests.py, then I'll
volunteer to write the test myself.
This is assuming that -N fixes the problem, of course.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: redundant "conflicts"
Posted by Marcus Comstedt <ma...@mc.pp.se>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Sure -- was it the regression test that established that the change
> didn't work? Sounds like it would be useful to have...
Not that this couldn't have been established just as well without the
test, but yes it was actually the test that did it. :-)
Ok, this probably will need some serious reviewing as it's my first
Subversion regression test, but here goes (invocation of the
particular test commented out since the code hasn't yet reached the
point from whence to regress)...
Index: ./subversion/tests/clients/cmdline/update_tests.py
===================================================================
--- ./subversion/tests/clients/cmdline/update_tests.py
+++ ./subversion/tests/clients/cmdline/update_tests.py Thu Jan 24 18:40:41 2002
@@ -475,6 +475,70 @@
'-r', '0')
+#----------------------------------------------------------------------
+
+def update_ignores_applied(sbox):
+ "ensure update ignores patches that have already been applied by hand"
+
+ if sbox.build():
+ return 1
+
+ wc_dir = sbox.wc_dir
+
+ # Make a file consisting of thee major parts, with a spelling
+ # error in each.
+ kappa_A1 = "This is the file 'cappa'."+"\n"*8
+ kappa_B1 = "It is devided into three parts by many LFs"+"\n"*8
+ kappa_C1 = "so that eash part can become a 'hunk'.\n"
+ kappa_path = os.path.join(wc_dir, 'kappa')
+ fp = open(kappa_path, 'w')
+ fp.write(kappa_A1+kappa_B1+kappa_C1)
+ fp.close()
+
+ # Add it to the repository as rev 2
+ svntest.main.run_svn(None, 'add', kappa_path)
+ svntest.main.run_svn(None, 'commit', kappa_path)
+
+ # Prepare fixes for all the spelling errors
+ kappa_A2 = kappa_A1[:18]+"k"+kappa_A1[19:]
+ kappa_B2 = kappa_B1[:7]+"i"+kappa_B1[8:]
+ kappa_C2 = kappa_C1[:10]+"c"+kappa_C1[11:]
+
+ # Apply fixes A and B, and commit (becomes rev 3)
+ fp = open(kappa_path, 'w')
+ fp.write(kappa_A2+kappa_B2+kappa_C1)
+ fp.close()
+ svntest.main.run_svn(None, 'commit', kappa_path)
+
+ # Now, revert the file to rev 2 and apply fixes B and C!
+ svntest.main.run_svn(None, 'update', '-r2', kappa_path)
+ fp = open(kappa_path, 'w')
+ fp.write(kappa_A1+kappa_B2+kappa_C2)
+ fp.close()
+
+ # Updating should now give us a merged file with all the three
+ # fixes and no conflicts
+ output_list = [ [kappa_path, None, {}, {'status' : 'G '}] ]
+ expected_output_tree = svntest.tree.build_generic_tree(output_list)
+ disk_list = svntest.main.copy_greek_tree()
+ disk_list.append(['kappa', kappa_A2+kappa_B2+kappa_C2, {}, {}])
+ expected_disk_tree = svntest.tree.build_generic_tree(disk_list)
+
+ # The expected status is that the file is modified from rev 3
+ status_list = svntest.actions.get_virginal_status_list(wc_dir, '3')
+ status_list.append([kappa_path, None, {},
+ {'status' : 'M ',
+ 'wc_rev' : '3',
+ 'repos_rev' : '3'}])
+ expected_status_tree = svntest.tree.build_generic_tree(status_list)
+
+ # Do it
+ return svntest.actions.run_and_verify_update(wc_dir,
+ expected_output_tree,
+ expected_disk_tree,
+ expected_status_tree)
+
+
########################################################################
# Run the tests
@@ -484,6 +548,7 @@
update_binary_file,
update_binary_file_2,
update_ignores_added,
+ # update_ignores_applied,
update_to_rev_zero,
# update_missing,
]
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: redundant "conflicts"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Marcus Comstedt <ma...@mc.pp.se> writes:
> The change didn't work, but I can send in just the regression test I
> made if you like.
Sure -- was it the regression test that established that the change
didn't work? Sounds like it would be useful to have...
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: redundant "conflicts"
Posted by Marcus Comstedt <ma...@mc.pp.se>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> :-) It's not as bad as all that, but if you can't get the regression
> :test done easily, don't sweat it and just send in the change.
The change didn't work, but I can send in just the regression test I
made if you like.
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: redundant "conflicts"
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Marcus Comstedt <ma...@mc.pp.se> writes:
> > Hey, see if it works! Try it out by adding this flag to our
> > invocations of 'patch' in libsvn_wc/get_editor.c:close_file(). If it
>
> Will do.
>
> > works, that's great. Give us a regression test, too. :-)
>
> Won't that require me to do battle with a Python? :-P
:-) It's not as bad as all that, but if you can't get the regression
:test done easily, don't sweat it and just send in the change.
Thanks,
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: redundant "conflicts"
Posted by Marcus Comstedt <ma...@mc.pp.se>.
Ben Collins-Sussman <su...@collab.net> writes:
> Marcus Comstedt <ma...@mc.pp.se> writes:
>
> > As it seems that gpatch is used to do the actual work, won't simply
> > adding the -N flag fix the problem?
>
> Hey, see if it works! Try it out by adding this flag to our
> invocations of 'patch' in libsvn_wc/get_editor.c:close_file(). If it
Will do.
> works, that's great. Give us a regression test, too. :-)
Won't that require me to do battle with a Python? :-P
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: redundant "conflicts"
Posted by Ben Collins-Sussman <su...@collab.net>.
Marcus Comstedt <ma...@mc.pp.se> writes:
> As it seems that gpatch is used to do the actual work, won't simply
> adding the -N flag fix the problem?
Hey, see if it works! Try it out by adding this flag to our
invocations of 'patch' in libsvn_wc/get_editor.c:close_file(). If it
works, that's great. Give us a regression test, too. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: redundant "conflicts"
Posted by Marcus Comstedt <ma...@mc.pp.se>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> i believe this is a known issue.
>
> see issue #563.
Ah, goody. Then I was just picked the wrong keywords to search for.
Or maybe since Ben couldn't find it either the issue contains the
wrong keywords. :-)
As it seems that gpatch is used to do the actual work, won't simply
adding the -N flag fix the problem?
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: redundant "conflicts"
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, Jan 23, 2002 at 11:16:43PM +0100, Marcus Comstedt wrote:
>
> Hm, I've been noticing a rather annoying thing about the update
> functionality:
>
> If my working copy is being updated to a new revision, and that
> revision contains changes that are already present in my working copy
> (as would be the case if I had sent in a patch, for example :), then
> this is detected as a conflict, with the .rej file containing a no-op
> transformation. cvs is not that stupid, so neither should svn be.
> This would probably not be a very high-priority concern, but I didn't
> see anything about it in the issue database, so I wanted to make sure
> it wasn't overlooked completely. :-)
i believe this is a known issue.
see issue #563.
http://subversion.tigris.org/issues/show_bug.cgi?id=563
-garrett
--
garrett rooney Unix was not designed to stop you from
rooneg@electricjellyfish.net doing stupid things, because that would
http://electricjellyfish.net/ stop you from doing clever things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: redundant "conflicts"
Posted by Ben Collins-Sussman <su...@collab.net>.
Marcus Comstedt <ma...@mc.pp.se> writes:
> Hm, I've been noticing a rather annoying thing about the update
> functionality:
>
> If my working copy is being updated to a new revision, and that
> revision contains changes that are already present in my working copy
> (as would be the case if I had sent in a patch, for example :), then
> this is detected as a conflict, with the .rej file containing a no-op
> transformation. cvs is not that stupid, so neither should svn be.
> This would probably not be a very high-priority concern, but I didn't
> see anything about it in the issue database, so I wanted to make sure
> it wasn't overlooked completely. :-)
Yeah, this bug has been brought up before. I don't see an issue
either; do you mind filing one?
The problem here is that if GNU 'patch' discovers that a hunk is
already present in the target, it still considers it a 'failed hunk'
and creates a .rej file anyway. Not sure what we can do about that.
(In the meantime, you can just 'svn revert' the file and the .rej will
vanish.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org