On Tue, May 06, 2008 at 03:03:04PM -0400, Karl Fogel wrote:
> "Rui, Guo" <timmyguo_at_mail.ustc.edu.cn> writes:
> > And about the grammar pitfall, the problem of mismatching singular and plural
> > is hard to catch my attention even when I'm checking for them, shy. This
> > problem seems common to Chinese English speakers since we do not distinguish
> > them in our mother tongue.
> 我知道,没问题 :-).
Wow~~ Incredible! You can speak Chinese! Where did you learn it from,huh? I'm
really curious about it. ^_^
> >> So I reverted the patch and tried with a clean trunk_at_r31039. This time,
> >> no failures. Could you look into this, please? Here's the adjusted
> >> version of the patch that I used. It should be functionally the same as
> >> yours, I only tweaked comments and formatting.
> > I should say sorry, Karl, for wasting your time on this. I admit that I did
> > not run a full check (too slow, don't you think?) before I submit the patch,
> > or I would have discovered this by myself.
> Oh, actually, it's okay to post a patch for review without first running
> 'make check'. Just make sure you say that in your mail, so people know
> what to expect.
Okay, I'll mention it next time if I only run a partial check.
> > The problem is that the "svn_client__make_local_parents()" function, which is
> > called by mkdir & copy logic, used a hard-coded svn_depth_empty when calling
> > svn_client_add4() to add it to the repository. This is OK before the patch is
> > applied, however, problem arise now since the depth of new directory is
> > unexpectedly set to empty. Changing the constant to svn_depth_infinity fixes
> > all the above failure.
> Ah, okay.
And the new patch was also included in the last reply, did you neglect it?
> > When digging into this problem, I found that 'svn merge' will still incur
> > local modification (to its children)even when --depth is empty, is this okay?
> I didn't quite understand. Can you explain that in more words?
Well, I observed something that I can't tell whether it is a Okay. I'll
show the detail this time.
In log_tests.py, there is a function 'merge_history_repos' used to prepare a
repository with complicated merge history. And it was in the function that I
found where the source of misc test failure lies in.
Here is a modified code snatch in that function. The original code used 'svn
mkdir' instead and caused the test failure. I explicitly add these directories
in depth empty here.
# Create trunk/tags/branches - r1
svntest.main.run_svn(None, 'add', '--depth=empty', 'trunk')
svntest.main.run_svn(None, 'add', '--depth=empty', 'tags')
svntest.main.run_svn(None, 'add', '--depth=empty', 'branches')
svntest.main.run_svn(None, 'ci', '-m',
'Add trunk/tags/branches structure.')
There is a merge later, as quoted here:
# Do some mergeing - r6
# Mergeinfo changes on /trunk:
# Merged /trunk:r2
# Merged /branches/a:r3-5
svntest.main.run_svn(None, 'merge', os.path.join('..', branch_a) + '@HEAD')
The command 'svn merge ../branches/a_at_HEAD' will derive its depth from the depth
of trunk -- svn_depth_empty. After this merge, I checked the state of wc:
$ svndev st
$ svndev diff
Property changes on: trunk
Property changes on: trunk/A
Property changes on: trunk/iota
It seems that the merge-info has recorded this merge. However, no merge on
file content actually happened.
The diff of branch a is as follows:
$ svndev diff -r3:5 branches/a
--- branches/a/A/mu (revision 3)
+++ branches/a/A/mu (revision 5)
@@ -1 +1,2 @@
This is the file 'mu'.
+Don't forget to look at 'upsilon', too.
\ No newline at end of file
--- branches/a/A/upsilon (revision 0)
+++ branches/a/A/upsilon (revision 5)
@@ -0,0 +1 @@
+This is the file 'upsilon'.
--- branches/a/iota (revision 3)
+++ branches/a/iota (revision 5)
@@ -1 +1,2 @@
This is the file 'iota'.
+'A' has changed a bit.
That's all. It's up to you to judge whether it is okay.
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-07 07:36:47 CEST