[Subversion Wiki] Trivial Update of SvnMergeTheory by JulianFoad
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Subversion Wiki for
change notification.
The SvnMergeTheory page has been changed by JulianFoad:
http://wiki.apache.org/subversion/SvnMergeTheory?action=diffrev1=3rev2=4
In the following example, two sync merges are shown. Let's jump straight to
examining the second one. (It is easy to see how the first one was performed).
+ {{attachment:merge-sync-1-req.png|requested sync merge}}
+
- {{attachment:merge-sync-1-req.png|requested sync merge}} To perform the
second sync merge (before it was committed as revision B5), Subversion:
+ To perform the second sync merge (before it was committed as revision B5),
Subversion:
* Found the common ancestor of A and B, which is point O on the diagram.
* Considered all the changes along the history of branch A, after the common
ancestor O up to and including A4. The changes are: A1, A2, A3, A4.
New attachment added to page SvnMergeTheory on Subversion Wiki
Dear Wiki user, You have subscribed to a wiki page SvnMergeTheory for change notification. An attachment has been added to that page by JulianFoad. Following detailed information is available: Attachment name: merge-graph-v3.py Attachment size: 7915 Attachment link: http://wiki.apache.org/subversion/SvnMergeTheory?action=AttachFiledo=gettarget=merge-graph-v3.py Page link: http://wiki.apache.org/subversion/SvnMergeTheory
New attachment added to page SvnMergeTheory on Subversion Wiki
Dear Wiki user, You have subscribed to a wiki page SvnMergeTheory for change notification. An attachment has been added to that page by JulianFoad. Following detailed information is available: Attachment name: merge-reint-1.ini Attachment size: 1126 Attachment link: http://wiki.apache.org/subversion/SvnMergeTheory?action=AttachFiledo=gettarget=merge-reint-1.ini Page link: http://wiki.apache.org/subversion/SvnMergeTheory
New attachment added to page SvnMergeTheory on Subversion Wiki
Dear Wiki user, You have subscribed to a wiki page SvnMergeTheory for change notification. An attachment has been added to that page by JulianFoad. Following detailed information is available: Attachment name: merge-reint-1.ini Attachment size: 342 Attachment link: http://wiki.apache.org/subversion/SvnMergeTheory?action=AttachFiledo=gettarget=merge-reint-1.ini Page link: http://wiki.apache.org/subversion/SvnMergeTheory
[Subversion Wiki] Update of SvnMergeTheory by JulianFoad
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Subversion Wiki for
change notification.
The SvnMergeTheory page has been changed by JulianFoad:
http://wiki.apache.org/subversion/SvnMergeTheory?action=diffrev1=4rev2=5
The only significant difference is that Subversion selects a base node that
is on the ''target'' branch rather than on the ''source'' branch.
== 3-way merge ==
+ Subversion currently performs any requested merge as a sequence of 3-way
merges. For simple ''sync'' and ''reintegrate'' merges, that's exactly what's
needed.
+
+ For a ''cherry-pick'' merge, that's not quite right, and a 4-way merge would
be more correct.
+
+ == Drawing Merge Graphs ==
+ The graphs in this page are constructed with the program
[[attachment:merge-graph-v3.py]] from configuration files such as
[[attachment:merge-reint-1.ini]].
+
{{{#!wiki comment
- Subversion performs a requested merge as a sequence of 3-way merges.
-
-
-
- What Subversion actually does is it looks along the (direct) history of the
source branch (A), and finds the first contiguous range of revisions along the
history of A that haven't
-
- ClearCase would perform this 'sync' merge exactly the same way, but it would
determine what
-
- Now look at a simple reintegrate scenario merge-reint-1.png.
-
-
- I believe you're quite right in saying that our reintegrate and sync merges
are restricted versions of a single general merge, iff we're talking about
merging patterns that consist only of sync and reintegrate merges.
-
- Remember that ClearCase doesn't track cherry-pick merges [2].
-
-
-
-
- Branko Čibej wrote:
-
- [Re. the difference between reintegrate and sync merges]
- [...] This looks like someone /started off/ with the assumption that
- a sync merge can take shortcuts where a reintegrate merge cannot;
-
-
The assumption is that the sync merge is one special case of merging and so
can take one set of shortcuts, while the reintegrate is another special case
and can take a different approach with its own set of restrictions and
short-cuts.
-
-
- but, so sorry, that's just plain nonsense. The
- cases are exactly symmetrical, all edge cases apply to both directions
- of the merge, a sync merge can encounter all the complications of a
- reintegrate merge.
-
- Yes, if our model of merging is
-
-
-
- [1] I've just been writing a merge graph drawing program to help produce
diagrams like this. Attached as 'merge-graph-v2.py'.
[2] ClearCase can perform a cherry-pick merge, and may even be able to
record some metadata about it, but (as far as I can discover) the merge
algorithm doesn't take account of cherry picks when working out what needs to
be merged. Git is similar; from what I read recently it has an extension that
can perform a cherry-pick merges and store cherry-pick metadata somewhere and
use it to track cherry picks when using that extension -- but the metadata is
completely separate from the fundamental merge DAG, and AFAIK the standard
merges don't recognize and account for cherry picks.
}}}
svn commit: r1238395 - /subversion/branches/1.7.x/STATUS
Author: philip Date: Tue Jan 31 11:07:48 2012 New Revision: 1238395 URL: http://svn.apache.org/viewvc?rev=1238395view=rev Log: * STATUS: Vote. Modified: subversion/branches/1.7.x/STATUS Modified: subversion/branches/1.7.x/STATUS URL: http://svn.apache.org/viewvc/subversion/branches/1.7.x/STATUS?rev=1238395r1=1238394r2=1238395view=diff == --- subversion/branches/1.7.x/STATUS (original) +++ subversion/branches/1.7.x/STATUS Tue Jan 31 11:07:48 2012 @@ -148,7 +148,7 @@ Candidate changes: Justification: Privately reported as AnkhSVN issue. Votes: - +1: rhuijben + +1: rhuijben, philip Veto-blocked changes: =
[Subversion Wiki] Trivial Update of SvnMergeTheory by JulianFoad
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Subversion Wiki for
change notification.
The SvnMergeTheory page has been changed by JulianFoad:
http://wiki.apache.org/subversion/SvnMergeTheory?action=diffrev1=5rev2=6
For a ''cherry-pick'' merge, that's not quite right, and a 4-way merge would
be more correct.
== Drawing Merge Graphs ==
- The graphs in this page are constructed with the program
[[attachment:merge-graph-v3.py]] from configuration files such as
[[attachment:merge-reint-1.ini]].
+ The graphs in this page are constructed with the program
[[attachment:merge-graph-v3.py]] from configuration files such as
[[attachment:merge-reint-1.txt]].
{{{#!wiki comment
svn commit: r1238422 [2/2] - in /subversion/branches/ev2-export: ./ subversion/bindings/javahl/ subversion/bindings/swig/python/libsvn_swig_py/ subversion/bindings/swig/python/tests/ subversion/includ
Modified:
subversion/branches/ev2-export/subversion/tests/cmdline/svntest/factory.py
URL:
http://svn.apache.org/viewvc/subversion/branches/ev2-export/subversion/tests/cmdline/svntest/factory.py?rev=1238422r1=1238421r2=1238422view=diff
==
--- subversion/branches/ev2-export/subversion/tests/cmdline/svntest/factory.py
(original)
+++ subversion/branches/ev2-export/subversion/tests/cmdline/svntest/factory.py
Tue Jan 31 12:07:06 2012
@@ -1612,6 +1612,11 @@ class TestFactory:
def ensure_path_var(self, wc, pathelements):
Given a path in a working copy, make sure we have a variable for it.
+
+# special case: if a path is '.', simply use wc_dir.
+if pathelements == ['.']:
+ return wc.py, wc.realpath
+
name = _.join(pathelements)
if wc.suffix is not None:
Modified: subversion/branches/ev2-export/tools/client-side/svnmucc/svnmucc.c
URL:
http://svn.apache.org/viewvc/subversion/branches/ev2-export/tools/client-side/svnmucc/svnmucc.c?rev=1238422r1=1238421r2=1238422view=diff
==
--- subversion/branches/ev2-export/tools/client-side/svnmucc/svnmucc.c
(original)
+++ subversion/branches/ev2-export/tools/client-side/svnmucc/svnmucc.c Tue Jan
31 12:07:06 2012
@@ -660,9 +660,9 @@ execute(const apr_array_header_t *action
for (i = 0; i actions-nelts; ++i)
{
struct action *action = APR_ARRAY_IDX(actions, i, struct action *);
+ const char *path1, *path2;
switch (action-action)
{
- const char *path1, *path2;
case ACTION_MV:
path1 = subtract_anchor(anchor, action-path[0], pool);
path2 = subtract_anchor(anchor, action-path[1], pool);
Modified: subversion/branches/ev2-export/tools/dist/backport.pl
URL:
http://svn.apache.org/viewvc/subversion/branches/ev2-export/tools/dist/backport.pl?rev=1238422r1=1238421r2=1238422view=diff
==
--- subversion/branches/ev2-export/tools/dist/backport.pl (original)
+++ subversion/branches/ev2-export/tools/dist/backport.pl Tue Jan 31 12:07:06
2012
@@ -194,7 +194,7 @@ sub handle_entry {
# TODO: this changes ./STATUS, which we're reading below, but
# on my system the loop in main() doesn't seem to care.
- merge %entry if prompt;
+ merge %entry if $ENV{YES} or prompt;
1;
}
[Subversion Wiki] Trivial Update of SvnMergeTheory by JulianFoad
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Subversion Wiki for
change notification.
The SvnMergeTheory page has been changed by JulianFoad:
http://wiki.apache.org/subversion/SvnMergeTheory?action=diffrev1=6rev2=7
}}}
Let's examine how Subversion performs a sync merge and how it performs a
reintegrate merge.
- In the following example, two sync merges are shown. Let's jump straight to
examining the second one. (It is easy to see how the first one was performed).
+ In the following example, two sync merges are shown. Let's jump straight to
examining the second one. (The first one is just a simpler case of the same
thing.)
{{attachment:merge-sync-1-req.png|requested sync merge}}
To perform the second sync merge (before it was committed as revision B5),
Subversion:
- * Found the common ancestor of A and B, which is point O on the diagram.
+ * Find the common ancestor of A and B (just following the plain lines of
descent, ignoring merges).
+ * That's state O on the diagram.
- * Considered all the changes along the history of branch A, after the common
ancestor O up to and including A4. The changes are: A1, A2, A3, A4.
+ * Consider all the changes along the history of branch A, after the common
ancestor O up to and including A4.
+ * That's changes A1, A2, A3, A4.
- * Looked at B's mergeinfo, to see what has already been merged from A. It
says A1 and A2.
+ * Look at B's mergeinfo, to see what has already been merged from A.
+ * That's changes A1 and A2.
- * Determined that the changes from A that have not yet been merged into B
are A3 and A4, according to the evidence of B's mergeinfo.
+ * Determine the changes from A that have not yet been merged into B,
according to the evidence of B's mergeinfo.
- * Performed a 3-way merge, using A2 as the base, from A4 into B (actually
the WC based on B4).
+ * That's changes A3 and A4.
+ * Perform a 3-way merge of A3 and A4 into B (actually into the WC based on
B4). The base of the 3-way merge is the predecessor of change A3, which is A2.
And then the user committed that WC as revision B5.
@@ -46, +50 @@
{{attachment:merge-reint-1.png|svn sync merge}}
- The only significant difference is that Subversion selects a base node that
is on the ''target'' branch rather than on the ''source'' branch.
+ The main significant difference is that Subversion selects a base node that
is on the ''target'' branch rather than on the ''source'' branch.
+
+ But what's the mergeinfo? [TODO...]
+
+
== 3-way merge ==
Subversion currently performs any requested merge as a sequence of 3-way
merges. For simple ''sync'' and ''reintegrate'' merges, that's exactly what's
needed.
[Subversion Wiki] Update of FrontPage by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on Subversion Wiki for change notification. The FrontPage page has been changed by JulianFoad: http://wiki.apache.org/subversion/FrontPage?action=diffrev1=15rev2=16 Comment: State that content is licensed under ALv2. This is the official Wiki of the [[http://subversion.apache.org/|Apache Subversion]] development community.BR Editing access is granted to Subversion committers -- just mail a request with your wiki username to [[mailto:d...@subversion.apache.org|dev@s.a.o]]. - HowTo DesignNotes - Prior to our use of this wiki, the Subversion project maintained design notes, how-to write-ups, and other miscellaneous bits of documentation in text files versioned alongside the Subversion source code. See MigratingOurNotes for pointers to those items and discussion around possibly migrating them into this wiki. ~-(TitleIndex | WordIndex | WikiUsage)-~ + The content of this Wiki is licensed under the [[http://www.apache.org/licenses/LICENSE-2.0|ALv2]]. +
svn commit: r1238450 - /subversion/trunk/tools/dev/merge-graph.py
Author: julianfoad
Date: Tue Jan 31 12:39:00 2012
New Revision: 1238450
URL: http://svn.apache.org/viewvc?rev=1238450view=rev
Log:
Add a script for drawing nice graphs of merging scenarios.
Added:
subversion/trunk/tools/dev/merge-graph.py (with props)
Added: subversion/trunk/tools/dev/merge-graph.py
URL:
http://svn.apache.org/viewvc/subversion/trunk/tools/dev/merge-graph.py?rev=1238450view=auto
==
--- subversion/trunk/tools/dev/merge-graph.py (added)
+++ subversion/trunk/tools/dev/merge-graph.py Tue Jan 31 12:39:00 2012
@@ -0,0 +1,271 @@
+#!/usr/bin/env python
+
+#
+#Licensed to the Apache Software Foundation (ASF) under one
+#or more contributor license agreements. See the NOTICE file
+#distributed with this work for additional information
+#regarding copyright ownership. The ASF licenses this file
+#to you under the Apache License, Version 2.0 (the
+#License); you may not use this file except in compliance
+#with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+#Unless required by applicable law or agreed to in writing,
+#software distributed under the License is distributed on an
+#AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+#KIND, either express or implied. See the License for the
+#specific language governing permissions and limitations
+#under the License.
+#
+
+args_message = 'GRAPH_CONFIG_FILE...'
+help_message = Produce pretty graphs representing branches and merging.
+For each config file specified, construct a graph and write it as a PNG
file.
+example =
+ [graph]
+ filename = merge-sync-1.png
+ title = Sync Merge: CC vs SVN
+ # Branches: (branch name, branched from node, first rev, last rev).
+ branches = [
+('A', 'O0', 1, 4),
+('O', None, 0, 0),
+('B', 'O0', 1, 5)
+]
+ # Changes: nodes in which a change was committed; merge targets need not
+ # be listed here.
+ changes = [
+'A1', 'A2', 'A3', 'A4',
+'B1', 'B2', 'B3', 'B4', 'B5'
+]
+ # Merges: (base node, source-right node, target node, label).
+ # Base is also known as source-left.
+ merges = [
+('O0', 'A:1', 'B3', 'sync'),
+('A2', 'A:3', 'B5', 'sync'),
+]
+ # Annotations for nodes: (node, annotation text).
+ annotations = [
+('A2', 'cc:YCA')
+]
+
+
+# Notes about different kinds of merge.
+#
+# A basic 3-way merge is ...
+#
+# The ClearCase style of merge is a 3-way merge.
+#
+# The Subversion style of merge (that is, one phase of a Subversion merge)
+# is a three-way merge with its base (typically the YCA) on the source branch.
+
+
+import sys
+import pydot
+from pydot import Node, Edge
+
+
+def mergeinfo_to_node_list(mi):
+ Convert a mergeinfo string such as '/foo:1,3-5*' into a list of
+ node names such as ['foo1', 'foo3', 'foo4', 'foo5'].
+ ### Doesn't yet strip the leading slash.
+ l = []
+ if mi:
+for mi_str in mi.split(' '):
+ path, ranges = mi_str.split(':')
+ for r in ranges.split(','):
+if r.endswith('*'):
+ # TODO: store use this 'non-inheritable' flag
+ # Remove the flag
+ r = r[:-1]
+rlist = r.split('-')
+r1 = int(rlist[0])
+if len(rlist) == 2:
+ r2 = int(rlist[1])
+else:
+ r2 = r1
+for rev in range(r1, r2 + 1):
+ l.append(path + str(rev))
+ return l
+
+
+class MergeGraph(pydot.Graph):
+ Base class, not intended for direct use. Use MergeDot for the main
+ graph and MergeSubgraph for a subgraph.
+
+ def mk_origin_node(graph, name):
+Add a node to the graph
+graph.add_node(Node(name + '0', label=name, shape='plaintext'))
+
+ def mk_invis_node(graph, name):
+Add a node to the graph
+graph.add_node(Node(name, style='invis'))
+
+ def mk_node(graph, name):
+Add a node to the graph, if not already present
+if not graph.get_node(name):
+ if name in graph.changes:
+graph.add_node(Node(name))
+ else:
+graph.add_node(Node(name, color='grey', label=''))
+
+ def mk_merge_target(graph, target_node, important):
+Add a merge target node to the graph.
+if important:
+ color = 'red'
+else:
+ color = 'black'
+graph.add_node(Node(target_node, color=color, fontcolor=color,
style='bold'))
+
+ def mk_edge(graph, name1, name2, **attrs):
+Add an ordinary edge to the graph
+graph.add_edge(Edge(name1, name2, dir='none', style='dotted',
color='grey', **attrs))
+
+ def mk_br_edge(graph, name1, name2):
+Add a branch-creation edge to the graph
+# Constraint=false to avoid the Y-shape skewing the nice parallel branch
lines
+graph.mk_edge(name1, name2, constraint='false')
+
+ def mk_merge_edge(graph, src_node, tgt_node,
[Subversion Wiki] Trivial Update of SvnMergeTheory by JulianFoad
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Subversion Wiki for
change notification.
The SvnMergeTheory page has been changed by JulianFoad:
http://wiki.apache.org/subversion/SvnMergeTheory?action=diffrev1=7rev2=8
But what's the mergeinfo? [TODO...]
-
-
== 3-way merge ==
Subversion currently performs any requested merge as a sequence of 3-way
merges. For simple ''sync'' and ''reintegrate'' merges, that's exactly what's
needed.
For a ''cherry-pick'' merge, that's not quite right, and a 4-way merge would
be more correct.
== Drawing Merge Graphs ==
- The graphs in this page are constructed with the program
[[attachment:merge-graph-v3.py]] from configuration files such as
[[attachment:merge-reint-1.txt]].
+ The graphs in this page are constructed with the program
[[http://svn.apache.org/viewvc/subversion/trunk/tools/dev/merge-graph.py|merge-graph.py]]
from configuration files such as [[attachment:merge-reint-1.txt]].
{{{#!wiki comment
[Subversion Wiki] Update of SvnMergeTheory by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on Subversion Wiki for change notification. The SvnMergeTheory page has been changed by JulianFoad: http://wiki.apache.org/subversion/SvnMergeTheory?action=diffrev1=8rev2=9 But what's the mergeinfo? [TODO...] == 3-way merge == - Subversion currently performs any requested merge as a sequence of 3-way merges. For simple ''sync'' and ''reintegrate'' merges, that's exactly what's needed. + Subversion currently performs any requested merge as a sequence of 3-way merges. For simple ''sync'' and ''reintegrate'' merges, that's exactly what's needed. Usually there is just one 3-way merge, but if cherry-picks are being skipped then Subversion breaks down the merge source range into sub-ranges and performs one 3-way merge per sub-range. - For a ''cherry-pick'' merge, that's not quite right, and a 4-way merge would be more correct. + For a ''cherry-pick'' merge, a 3-way merge is not quite right, and a [[http://svn.apache.org/viewvc/subversion/trunk/notes/variance-adjusted-patching.html|4-way merge]] would be more correct. + + [TODO: diagram of cherry-pick as 4-way merge] == Drawing Merge Graphs == The graphs in this page are constructed with the program [[http://svn.apache.org/viewvc/subversion/trunk/tools/dev/merge-graph.py|merge-graph.py]] from configuration files such as [[attachment:merge-reint-1.txt]].
New attachment added to page SvnMergeTheory on Subversion Wiki
Dear Wiki user, You have subscribed to a wiki page SvnMergeTheory for change notification. An attachment has been added to that page by JulianFoad. Following detailed information is available: Attachment name: merge-cherry-1.png Attachment size: 30451 Attachment link: http://wiki.apache.org/subversion/SvnMergeTheory?action=AttachFiledo=gettarget=merge-cherry-1.png Page link: http://wiki.apache.org/subversion/SvnMergeTheory
New attachment added to page SvnMergeTheory on Subversion Wiki
Dear Wiki user, You have subscribed to a wiki page SvnMergeTheory for change notification. An attachment has been added to that page by JulianFoad. Following detailed information is available: Attachment name: merge-sync-1-req.txt Attachment size: 317 Attachment link: http://wiki.apache.org/subversion/SvnMergeTheory?action=AttachFiledo=gettarget=merge-sync-1-req.txt Page link: http://wiki.apache.org/subversion/SvnMergeTheory
New attachment added to page SvnMergeTheory on Subversion Wiki
Dear Wiki user, You have subscribed to a wiki page SvnMergeTheory for change notification. An attachment has been added to that page by JulianFoad. Following detailed information is available: Attachment name: merge-cherry-1.txt Attachment size: 369 Attachment link: http://wiki.apache.org/subversion/SvnMergeTheory?action=AttachFiledo=gettarget=merge-cherry-1.txt Page link: http://wiki.apache.org/subversion/SvnMergeTheory
New attachment added to page SvnMergeTheory on Subversion Wiki
Dear Wiki user, You have subscribed to a wiki page SvnMergeTheory for change notification. An attachment has been added to that page by JulianFoad. Following detailed information is available: Attachment name: merge-sync-1-svn.txt Attachment size: 360 Attachment link: http://wiki.apache.org/subversion/SvnMergeTheory?action=AttachFiledo=gettarget=merge-sync-1-svn.txt Page link: http://wiki.apache.org/subversion/SvnMergeTheory
[Subversion Wiki] Update of SvnMergeTheory by JulianFoad
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Subversion Wiki for
change notification.
The SvnMergeTheory page has been changed by JulianFoad:
http://wiki.apache.org/subversion/SvnMergeTheory?action=diffrev1=9rev2=10
What if, instead of a second sync merge, at that point we try a reintegrate
instead?
- {{attachment:merge-reint-1.png|svn sync merge}}
+ {{attachment:merge-reint-1.png|svn reintegrate merge}}
The main significant difference is that Subversion selects a base node that
is on the ''target'' branch rather than on the ''source'' branch.
@@ -59, +59 @@
For a ''cherry-pick'' merge, a 3-way merge is not quite right, and a
[[http://svn.apache.org/viewvc/subversion/trunk/notes/variance-adjusted-patching.html|4-way
merge]] would be more correct.
- [TODO: diagram of cherry-pick as 4-way merge]
+ {{attachment:merge-cherry-1.png|Cherry-Pick as 4-way Merge}}
== Drawing Merge Graphs ==
The graphs in this page are constructed with the program
[[http://svn.apache.org/viewvc/subversion/trunk/tools/dev/merge-graph.py|merge-graph.py]]
from configuration files such as [[attachment:merge-reint-1.txt]].
New attachment added to page SvnMergeTheory on Subversion Wiki
Dear Wiki user, You have subscribed to a wiki page SvnMergeTheory for change notification. An attachment has been added to that page by JulianFoad. Following detailed information is available: Attachment name: merge-cherry-3way.png Attachment size: 29527 Attachment link: http://wiki.apache.org/subversion/SvnMergeTheory?action=AttachFiledo=gettarget=merge-cherry-3way.png Page link: http://wiki.apache.org/subversion/SvnMergeTheory
New attachment added to page SvnMergeTheory on Subversion Wiki
Dear Wiki user, You have subscribed to a wiki page SvnMergeTheory for change notification. An attachment has been added to that page by JulianFoad. Following detailed information is available: Attachment name: merge-cherry-3way.txt Attachment size: 372 Attachment link: http://wiki.apache.org/subversion/SvnMergeTheory?action=AttachFiledo=gettarget=merge-cherry-3way.txt Page link: http://wiki.apache.org/subversion/SvnMergeTheory
New attachment added to page SvnMergeTheory on Subversion Wiki
Dear Wiki user, You have subscribed to a wiki page SvnMergeTheory for change notification. An attachment has been added to that page by JulianFoad. Following detailed information is available: Attachment name: merge-cherry-4way.png Attachment size: 30280 Attachment link: http://wiki.apache.org/subversion/SvnMergeTheory?action=AttachFiledo=gettarget=merge-cherry-4way.png Page link: http://wiki.apache.org/subversion/SvnMergeTheory
svn commit: r1238645 - in /subversion/trunk/subversion: libsvn_delta/compat.c libsvn_wc/update_editor.c
Author: hwright
Date: Tue Jan 31 14:58:38 2012
New Revision: 1238645
URL: http://svn.apache.org/viewvc?rev=1238645view=rev
Log:
Ev2 shims: Introduce a proper callback for the unlocking of files, rather than
using a (technically no-op) deletion of a non-existant property. Right now,
this all happens in the shims, so external code need not worry about it, but
eventually callers will need to provide this callback if they are interested
in such events.
* subversion/libsvn_wc/update_editor.c
(fetch_props_func): Remove.
(make_editor): Use the standard libsvn_wc fetch props func.
* subversion/libsvn_delta/compat.c
(unlock_func_t): New.
(ev2_edit_baton): Add new members.
(action_code_t): Add new action.
(process_actions): Handle the new action.
(ev2_change_file_prop): Trap the special property, and translate it to a
separate action.
(delta_from_editor): Add new params and stash them in the baton.
(do_unlock): New.
(editor_from_delta): Add new output params, and set them appropriately.
(svn_editor__insert_shims): Pass the unlock baton and func between shims.
Modified:
subversion/trunk/subversion/libsvn_delta/compat.c
subversion/trunk/subversion/libsvn_wc/update_editor.c
Modified: subversion/trunk/subversion/libsvn_delta/compat.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_delta/compat.c?rev=1238645r1=1238644r2=1238645view=diff
==
--- subversion/trunk/subversion/libsvn_delta/compat.c (original)
+++ subversion/trunk/subversion/libsvn_delta/compat.c Tue Jan 31 14:58:38 2012
@@ -91,7 +91,18 @@ svn_compat_wrap_file_rev_handler(svn_fil
* The general idea here is that we have to see *all* the actions on a node's
* parent before we can process that node, which means we need to buffer a
* large amount of information in the dir batons, and then process it in the
- * close_directory() handler. */
+ * close_directory() handler.
+ *
+ * There are a few ways we alter the callback stream. One is when unlocking
+ * paths. To tell a client a path should be unlocked, the server sends a
+ * prop-del for the SVN_PROP_ENTRY_LOCK_TOKEN property. This causes problems,
+ * since the client doesn't have this property in the first place, but the
+ * deletion has side effects (unlike deleting a non-existent regular property
+ * would). To solve this, we introduce *another* function into the API, not
+ * a part of the Ev2 callbacks, but a companion which is used to register
+ * the unlock of a path. See ev2_change_file_prop() for implemenation
+ * details.
+ */
typedef svn_error_t *(*start_edit_func_t)(
void *baton,
@@ -102,6 +113,11 @@ typedef svn_error_t *(*target_revision_f
svn_revnum_t target_revision,
apr_pool_t *scratch_pool);
+typedef svn_error_t *(*unlock_func_t)(
+void *baton,
+const char *path,
+apr_pool_t *scratch_pool);
+
/* svn_editor__See insert_shims() for more information. */
struct extra_baton
{
@@ -125,6 +141,9 @@ struct ev2_edit_baton
svn_delta_fetch_base_func_t fetch_base_func;
void *fetch_base_baton;
+
+ unlock_func_t do_unlock;
+ void *unlock_baton;
};
struct ev2_dir_baton
@@ -155,7 +174,8 @@ enum action_code_t
ACTION_ADD,
ACTION_DELETE,
ACTION_ADD_ABSENT,
- ACTION_SET_TEXT
+ ACTION_SET_TEXT,
+ ACTION_UNLOCK
};
struct path_action
@@ -337,6 +357,12 @@ process_actions(void *edit_baton,
break;
}
+ case ACTION_UNLOCK:
+{
+ SVN_ERR(eb-do_unlock(eb-unlock_baton, path, scratch_pool));
+ break;
+}
+
default:
SVN_ERR_MALFUNCTION();
}
@@ -754,6 +780,15 @@ ev2_change_file_prop(void *file_baton,
struct ev2_file_baton *fb = file_baton;
struct prop_args *p_args = apr_palloc(fb-eb-edit_pool, sizeof(*p_args));
+ if (!strcmp(name, SVN_PROP_ENTRY_LOCK_TOKEN) value == NULL)
+{
+ /* We special case the lock token propery deletion, which is the
+ server's way of telling the client to unlock the path. */
+ SVN_ERR(add_action(fb-eb, fb-path, ACTION_UNLOCK, NULL));
+}
+
+ /* We also pass through the deletion, since there may actually exist such
+ a property we want to get rid of. In the worse case, this is a no-op. */
p_args-name = apr_pstrdup(fb-eb-edit_pool, name);
p_args-value = value ? svn_string_dup(value, fb-eb-edit_pool) : NULL;
p_args-base_revision = fb-base_revision;
@@ -809,6 +844,8 @@ static svn_error_t *
delta_from_editor(const svn_delta_editor_t **deditor,
void **dedit_baton,
svn_editor_t *editor,
+ unlock_func_t unlock_func,
+ void *unlock_baton,
svn_boolean_t *found_abs_paths,
svn_delta_fetch_props_func_t fetch_props_func,
void *fetch_props_baton,
@@ -851,6 +888,9 @@ delta_from_editor(const svn_delta_editor
[Subversion Wiki] Update of SvnMergeTheory by JulianFoad
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Subversion Wiki for
change notification.
The SvnMergeTheory page has been changed by JulianFoad:
http://wiki.apache.org/subversion/SvnMergeTheory?action=diffrev1=10rev2=11
== 3-way merge ==
Subversion currently performs any requested merge as a sequence of 3-way
merges. For simple ''sync'' and ''reintegrate'' merges, that's exactly what's
needed. Usually there is just one 3-way merge, but if cherry-picks are being
skipped then Subversion breaks down the merge source range into sub-ranges and
performs one 3-way merge per sub-range.
- For a ''cherry-pick'' merge, a 3-way merge is not quite right, and a
[[http://svn.apache.org/viewvc/subversion/trunk/notes/variance-adjusted-patching.html|4-way
merge]] would be more correct.
+ For a ''cherry-pick'' merge, a 3-way merge is not quite right:
+ {{attachment:merge-cherry-3way.png|Cherry-Pick as 3-way Merge}}
+
+ ... which tries to merge the change from ''old'' to ''theirs'' (so far, so
good) with the change from ''old'' to ''mine''. The trouble is that the latter
diff includes not only changes that were made deliberately in B, such as B3,
but also the ''reverse'' of some changes that were made earlier in A, such as
(minus)A2 and (minus)A1. In simple cases that's fine, but we could do better.
[TODO: Describe what goes wrong with it. Is it more chance of conflicts?]
+
+ A
[[http://svn.apache.org/viewvc/subversion/trunk/notes/variance-adjusted-patching.html|4-way
merge]] would be more correct:
+
- {{attachment:merge-cherry-1.png|Cherry-Pick as 4-way Merge}}
+ {{attachment:merge-cherry-4way.png|Cherry-Pick as 4-way Merge}}
== Drawing Merge Graphs ==
The graphs in this page are constructed with the program
[[http://svn.apache.org/viewvc/subversion/trunk/tools/dev/merge-graph.py|merge-graph.py]]
from configuration files such as [[attachment:merge-reint-1.txt]].
[Subversion Wiki] Trivial Update of SvnMergeTheory by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on Subversion Wiki for change notification. The SvnMergeTheory page has been changed by JulianFoad: http://wiki.apache.org/subversion/SvnMergeTheory?action=diffrev1=11rev2=12 But what's the mergeinfo? [TODO...] - == 3-way merge == + == 3-way or 4-way Merge == Subversion currently performs any requested merge as a sequence of 3-way merges. For simple ''sync'' and ''reintegrate'' merges, that's exactly what's needed. Usually there is just one 3-way merge, but if cherry-picks are being skipped then Subversion breaks down the merge source range into sub-ranges and performs one 3-way merge per sub-range. For a ''cherry-pick'' merge, a 3-way merge is not quite right:
svn commit: r1238657 - in /subversion/branches/ev2-export/subversion: include/svn_delta.h libsvn_client/export.c libsvn_delta/compat.c
Author: hwright
Date: Tue Jan 31 15:18:50 2012
New Revision: 1238657
URL: http://svn.apache.org/viewvc?rev=1238657view=rev
Log:
On the ev2-export branch:
Update API declarations and consumers in the wake of the merge in r1238653.
* subversion/include/svn_delta.h
(svn_delta_unlock_func_t): New.
(svn_delta__editor_from_delta, svn_delta__delta_from_editor): Update to
match function definitions.
* subversion/libsvn_client/export.c
(get_editor): Provide a NULL unlock func/baton, since we don't care about
that in the context of a export.
* subversion/libsvn_delta/compat.c
(unlock_func_t): Remove.
(ev2_edit_baton, svn_delta__delta_from_editor, svn_delta__editor_from_delta,
svn_editor__insert_shims): Update references.
Modified:
subversion/branches/ev2-export/subversion/include/svn_delta.h
subversion/branches/ev2-export/subversion/libsvn_client/export.c
subversion/branches/ev2-export/subversion/libsvn_delta/compat.c
Modified: subversion/branches/ev2-export/subversion/include/svn_delta.h
URL:
http://svn.apache.org/viewvc/subversion/branches/ev2-export/subversion/include/svn_delta.h?rev=1238657r1=1238656r2=1238657view=diff
==
--- subversion/branches/ev2-export/subversion/include/svn_delta.h (original)
+++ subversion/branches/ev2-export/subversion/include/svn_delta.h Tue Jan 31
15:18:50 2012
@@ -1160,6 +1160,12 @@ typedef svn_error_t *(*svn_delta__target
svn_revnum_t target_revision,
apr_pool_t *scratch_pool);
+typedef svn_error_t *(*svn_delta_unlock_func_t)(
+void *baton,
+const char *path,
+apr_pool_t *scratch_pool);
+
+
/* svn_editor__See insert_shims() for more information. */
struct svn_delta__extra_baton
{
@@ -1172,6 +1178,8 @@ struct svn_delta__extra_baton
svn_error_t *
svn_delta__editor_from_delta(svn_editor_t **editor_p,
struct svn_delta__extra_baton **exb,
+ svn_delta_unlock_func_t *unlock_func,
+ void **unlock_baton,
const svn_delta_editor_t *deditor,
void *dedit_baton,
svn_boolean_t *send_abs_paths,
@@ -1189,6 +1197,8 @@ svn_error_t *
svn_delta__delta_from_editor(const svn_delta_editor_t **deditor,
void **dedit_baton,
svn_editor_t *editor,
+ svn_delta_unlock_func_t unlock_func,
+ void *unlock_baton,
svn_boolean_t *found_abs_paths,
svn_delta_fetch_props_func_t fetch_props_func,
void *fetch_props_baton,
Modified: subversion/branches/ev2-export/subversion/libsvn_client/export.c
URL:
http://svn.apache.org/viewvc/subversion/branches/ev2-export/subversion/libsvn_client/export.c?rev=1238657r1=1238656r2=1238657view=diff
==
--- subversion/branches/ev2-export/subversion/libsvn_client/export.c (original)
+++ subversion/branches/ev2-export/subversion/libsvn_client/export.c Tue Jan 31
15:18:50 2012
@@ -893,7 +893,7 @@ get_editor(const svn_delta_editor_t **ex
*found_abs_paths = TRUE;
SVN_ERR(svn_delta__delta_from_editor(export_editor, edit_baton,
- editor, found_abs_paths,
+ editor, NULL, NULL, found_abs_paths,
fetch_props_func, eb,
fetch_base_func, eb,
exb, result_pool));
Modified: subversion/branches/ev2-export/subversion/libsvn_delta/compat.c
URL:
http://svn.apache.org/viewvc/subversion/branches/ev2-export/subversion/libsvn_delta/compat.c?rev=1238657r1=1238656r2=1238657view=diff
==
--- subversion/branches/ev2-export/subversion/libsvn_delta/compat.c (original)
+++ subversion/branches/ev2-export/subversion/libsvn_delta/compat.c Tue Jan 31
15:18:50 2012
@@ -105,12 +105,6 @@ svn_compat_wrap_file_rev_handler(svn_fil
*/
-typedef svn_error_t *(*unlock_func_t)(
-void *baton,
-const char *path,
-apr_pool_t *scratch_pool);
-
-
struct ev2_edit_baton
{
svn_editor_t *editor;
@@ -127,7 +121,7 @@ struct ev2_edit_baton
svn_delta_fetch_base_func_t fetch_base_func;
void *fetch_base_baton;
- unlock_func_t do_unlock;
+ svn_delta_unlock_func_t do_unlock;
void *unlock_baton;
};
@@ -829,7 +823,7 @@ svn_error_t *
svn_delta__delta_from_editor(const svn_delta_editor_t **deditor,
void **dedit_baton,
svn_editor_t *editor,
- unlock_func_t unlock_func,
+ svn_delta_unlock_func_t unlock_func,
void *unlock_baton,
svn_boolean_t *found_abs_paths,
svn_delta_fetch_props_func_t fetch_props_func,
@@ -1665,7 +1659,7 @@ do_unlock(void *baton,
svn_error_t
[Subversion Wiki] Update of InheritedProperties by pburba
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Subversion Wiki for
change notification.
The InheritedProperties page has been changed by pburba:
http://wiki.apache.org/subversion/InheritedProperties?action=diffrev1=8rev2=9
Comment:
Don't require that Subversion reserved inheritable properties have any special
namespace beyond the standard svn: prefix.
Inheritable properties will be identified by a prefix on the property name.
1. Custom user properties will use the svn:inheritable: prefix.
- 1. Reserved Subversion inheritable properties will use the svn:i: prefix.
+ 1. Existing Subversion reserved properties will 'not' become
inheritable, they will function as they always have. New reserved Subversion
properties may be introduced that are inheritable by definition, but such
properties are not required to use any special namespace, beyond the normal
svn: prefix.
{{{#!wiki note
[JAF] Need to define the set of valid names and values. If they're in the
'svn:' namespace, then I imagine it needs to be (a subset of) the set of valid
'svn:' props -- mainly this means the values are UTF-8.
[Subversion Wiki] Update of InheritedProperties by pburba
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Subversion Wiki for
change notification.
The InheritedProperties page has been changed by pburba:
http://wiki.apache.org/subversion/InheritedProperties?action=diffrev1=9rev2=10
Comment:
Remove svn:i: examples and replace with svn:inheritable:
[danielsh] Using the 'svn:inheritable:' namespace precludes a property from
being both inheritable and ${some_future_semantics}, since a property name
cannot be simultaneously in the 'svn:inheritable:' namespace and in the
'svn:{some_future_semantics}:' namespace.
}}}
== Inheritance Rules ==
- Inheritance will be very similar to the current svn:mergeinfo inheritance
model. For a given inheritable property 'svn:i:X':
+ Inheritance will be very similar to the current svn:mergeinfo inheritance
model. For a given inheritable property 'svn:inheritable:X':
- 1. A path 'with' svn:i:X' explicitly set on it never inherits that
property (i.e. a path can only inherit a property it doesn't have set on
itself).' '
+ 1. A path 'with' svn:inheritable:X' explicitly set on it never
inherits that property (i.e. a path can only inherit a property it doesn't have
set on itself).' '
- 1. A repository path@REV 'without' the 'svn:i:X' property explicitly
set on it (we'll refer to this as the 'child' path from here on) may inherit
the property from the path's nearest path-wise ancestor@REV with the 'svn:i:X'
property explicitly set on it (we'll refer to this as the 'parent' path).
+ 1. A repository path@REV 'without' the 'svn:inheritable:X' property
explicitly set on it (we'll refer to this as the 'child' path from here on) may
inherit the property from the path's nearest path-wise ancestor@REV with the
'svn:inheritable:X' property explicitly set on it (we'll refer to this as the
'parent' path).
- 1. A 'working copy' child path 'without' the 'svn:i:X'
property explicitly set on it may inherit the property from the path's nearest
path-wise ancestor in the working copy.
+ 1. A 'working copy' child path 'without' the
'svn:inheritable:X' property explicitly set on it may inherit the property from
the path's nearest path-wise ancestor in the working copy.
* For working copies with no switched subtrees, this inheritance can occur
from any parent path up to the root of the working copy.
* If the path is located within a switched subtree then the inheritance can
occur up to the root of the switched subtree.
* Unlike svn:mergeinfo and like tsvn:auto-props, inheritance across
mixed-revision boundaries in the working copy is allowed.
- * If a working copy child path doesn't find a parent with 'svn:i:X' that it
can inherit from before it reaches the working copy (or switched subtree) root,
then it may inherit the property from the inherited properties cache (see
below).
+ * If a working copy child path doesn't find a parent with
'svn:inheritable:X' that it can inherit from before it reaches the working copy
(or switched subtree) root, then it may inherit the property from the inherited
properties cache (see below).
{{{#!wiki note
[JAF] What is the unifying principle behind the set of rules? For
example, a principle could be:BR
Inheritance within a WC is based on inheritance within a single revision
of the tree structure. Thus, a WC base node inherits from its repository
parent in its repository revision, no matter whether that is present in the WC.
The working version of the WC tree is treated as a single revision: an as yet
unnumbered prototype for a revision that might be committed into the repository
(or might not)[1]. Thus, a WC working node[2] inherits from the parent node
that it would have in the repository if the current WC were committed in
full.BR
svn commit: r1238683 - /subversion/trunk/subversion/libsvn_delta/compat.c
Author: hwright Date: Tue Jan 31 16:13:30 2012 New Revision: 1238683 URL: http://svn.apache.org/viewvc?rev=1238683view=rev Log: Ev2 shims: Document the main shim entry points. * subversion/libsvn_delta/compat.c (delta_from_editor, editor_from_delta): Add a docstring. Modified: subversion/trunk/subversion/libsvn_delta/compat.c Modified: subversion/trunk/subversion/libsvn_delta/compat.c URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_delta/compat.c?rev=1238683r1=1238682r2=1238683view=diff == --- subversion/trunk/subversion/libsvn_delta/compat.c (original) +++ subversion/trunk/subversion/libsvn_delta/compat.c Tue Jan 31 16:13:30 2012 @@ -840,6 +840,26 @@ ev2_abort_edit(void *edit_baton, return svn_error_trace(svn_editor_abort(eb-editor)); } +/* Return a svn_delta_editor_t * in DEDITOR, with an accompanying baton in + * DEDITOR_BATON, which will be driven by EDITOR. These will both be + * allocated in RESULT_POOL, which may become large and long-lived; + * SCRATCH_POOL is used for temporary allocations. + * + * The other parameters are as follows: + * - UNLOCK_FUNC / UNLOCK_BATON: A callback / baton which will be called + * when an unlocking action is received. + * - FOUND_ABS_PATHS: A pointer to a boolean flag which will be set if + * this shim determines that it is receiving absolute paths. + * - FETCH_PROPS_FUNC / FETCH_PROPS_BATON: A callback / baton pair which + * will be used by the shim handlers if they need to determine the + * existing properties on a path. + * - FETCH_BASE_FUNC / FETCH_BASE_BATON: A callback / baton pair which will + * be used by the shims handlers if they need to determine the base + * text of a path. It should only be invoked for files. + * - EXB: An 'extra baton' which is used to communicate between the shims. + * Its callbacks should be invoked at the appropriate time by this + * shim. + */ static svn_error_t * delta_from_editor(const svn_delta_editor_t **deditor, void **dedit_baton, @@ -1677,6 +1697,32 @@ do_unlock(void *baton, return SVN_NO_ERROR; } +/* Return an svn_editor_t * in EDITOR_P which will be driven by + * DEDITOR/DEDIT_BATON. EDITOR_P is allocated in RESULT_POOL, which may + * become large and long-lived; SCRATCH_POOL is used for temporary + * allocations. + * + * The other parameters are as follows: + * - EXB: An 'extra_baton' used for passing information between the coupled + * shims. This includes actions like 'start edit' and 'set target'. + * As this shim receives these actions, it provides the extra baton + * to its caller. + * - UNLOCK_FUNC / UNLOCK_BATON: A callback / baton pair which a caller + * can use to notify this shim that a path should be unlocked (in the + * 'svn lock' sense). As this shim receives this action, it provides + * this callback / baton to its caller. + * - SEND_ABS_PATHS: A pointer which will be set prior to this edit (but + * not necessarily at the invocation of editor_from_delta()),and + * which indicates whether incoming paths should be expected to + * be absolute or relative. + * - CANCEL_FUNC / CANCEL_BATON: The usual; folded into the produced editor. + * - FETCH_KIND_FUNC / FETCH_KIND_BATON: A callback / baton pair which will + * be used by the shim handlers if they need to determine the kind of + * a path. + * - FETCH_PROPS_FUNC / FETCH_PROPS_BATON: A callback / baton pair which + * will be used by the shim handlers if they need to determine the + * existing properties on a path. + */ static svn_error_t * editor_from_delta(svn_editor_t **editor_p, struct extra_baton **exb,
[Subversion Wiki] Update of InheritedProperties by pburba
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Subversion Wiki for
change notification.
The InheritedProperties page has been changed by pburba:
http://wiki.apache.org/subversion/InheritedProperties?action=diffrev1=10rev2=11
Comment:
Tweak suggested new APIs to allow retrieval of explicit and/or inherited
properties.
bar
}}}
== API Changes ==
- Rev svn_client_proplist3 to svn_client_proplist4, adding the svn_boolean_t
argument '''get_target_inherited_props''':
+ Rev svn_proplist_receiver_t to svn_proplist_receiver2_t, adding the argument
'''apr_hash_t *inherited_prop_hash'''. Also allow the possibility that the
existing apr_hash_t *prop_hash argument may be null:
+ {{{#!cplusplus
- '### TBD: Do we want to rev svn_proplist_receiver_t so it can
differentiate between explicit and inherited properties?'
-
- {{{
/**
+ * The callback invoked by svn_client_proplist4(). Each invocation
+ * provides the regular and/or inherited properties of @a path which
+ * is either a WC path or a URL. If @a prop_hash is not null, then it
+ * maps explicit property names (char *) to explicit property
+ * values (svn_string_t *). If @a inherited_prop_hash is not null,
+ * then it maps inherited property names (char *) to explicit property
+ * values (svn_string_t *). Use @a pool for all temporary allocations.
+ *
+ * @since New in 1.8.
+ */
+ typedef svn_error_t *(*svn_proplist_receiver2_t)(
+ void *baton,
+ const char *path,
+ apr_hash_t *prop_hash,
+ apr_hash_t *inherited_prop_hash,
+ apr_pool_t *pool);
+ }}}
+ Rev svn_client_proplist3 to svn_client_proplist4, adding the argument
svn_boolean_t '''get_target_inherited_props''':
+
+ {{{#!cplusplus
+ /**
- * Invoke @a receiver with @a receiver_baton to return the regular properties
+ * Invoke @a receiver with @a receiver_baton to return the regular explicit,
and
- * of @a target, a URL or working copy path. @a receiver will be called
- * for each path encountered.
+ * possibly the inherited, properties of @a target, a URL or working copy
path.
+ * @a receiver will be called for each path encountered.
*
* @a target is a WC path or a URL.
*
- * If @a revision-kind is #svn_opt_revision_unspecified, then get
+ * If @a revision-kind is #svn_opt_revision_unspecified, then get the
- * properties from the working copy, if @a target is a working copy
- * path, or from the repository head if @a target is a URL. Else get
- * the properties as of @a revision. The actual node revision
- * selected is determined by the path as it exists in @a peg_revision.
- * If @a peg_revision-kind is #svn_opt_revision_unspecified, then it
- * defaults to #svn_opt_revision_head for URLs or
+ * explicit (and possibly the inherited) properties from the working copy,
+ * if @a target is a working copy path, or from the repository head if
+ * @a target is a URL. Else get the properties as of @a revision.
+ * The actual node revision selected is determined by the path as it exists
+ * in @a peg_revision. If @a peg_revision-kind is
+ * #svn_opt_revision_unspecified, then it defaults to #svn_opt_revision_head
- * #svn_opt_revision_working for WC targets. Use the authentication
+ * for URLs or #svn_opt_revision_working for WC targets. Use the
- * baton cached in @a ctx for authentication if contacting the
+ * authentication baton cached in @a ctx for authentication if contacting
- * repository.
+ * the repository.
*
* If @a depth is #svn_depth_empty, list only the properties of
* @a target itself. If @a depth is #svn_depth_files, and
@@ -218, +237 @@
svn_depth_t depth,
const apr_array_header_t *changelists,
svn_boolean_t get_target_inherited_props,
- svn_proplist_receiver_t receiver,
+ svn_proplist_receiver2_t receiver,
void *receiver_baton,
svn_client_ctx_t *ctx,
apr_pool_t *pool);
}}}
- Rev svn_client_propget4 to svn_client_propget5, adding the svn_boolean_t
argument '''get_target_inherited_prop''':
+ Rev svn_client_propget4 to svn_client_propget5, adding the argument
'''svn_string_t **target_inherited_prop''':
- {{{
+ {{{#!cplusplus
/**
* Set @a *props to a hash table whose keys are absolute paths or URLs
- * of items on which property @a propname is set, and whose values are
+ * of items on which property @a propname is explicitly set, and whose
- * `#svn_string_t *' representing the property value for @a propname
+ * values are `#svn_string_t *' representing the property value for
- * at that path.
+ * @a propname at that path.
+ *
+ * If @a target_inherited_prop is not null, then set
+ * @a *target_inherited_prop to the value of @a propname which @a target
+ * inherits from its nearest parent. If @a target is a working copy path,
+ * then @a target may inherit properties
svn commit: r1238896 - /subversion/trunk/subversion/svnrdump/svnrdump.c
Author: hwright
Date: Wed Feb 1 01:22:26 2012
New Revision: 1238896
URL: http://svn.apache.org/viewvc?rev=1238896view=rev
Log:
Ensure we close our edit in svnrdump. While typically a no-op, it's still
good form.
* subversion/svnrdump/svnrdump.c
(replay_revend): Close the edit.
Modified:
subversion/trunk/subversion/svnrdump/svnrdump.c
Modified: subversion/trunk/subversion/svnrdump/svnrdump.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/svnrdump/svnrdump.c?rev=1238896r1=1238895r2=1238896view=diff
==
--- subversion/trunk/subversion/svnrdump/svnrdump.c (original)
+++ subversion/trunk/subversion/svnrdump/svnrdump.c Wed Feb 1 01:22:26 2012
@@ -240,6 +240,9 @@ replay_revend(svn_revnum_t revision,
{
/* No resources left to free. */
struct replay_baton *rb = replay_baton;
+
+ SVN_ERR(editor-close_edit(edit_baton, pool));
+
if (! rb-quiet)
SVN_ERR(svn_cmdline_fprintf(stderr, pool, * Dumped revision %lu.\n,
revision));
svn commit: r1238904 - /subversion/trunk/subversion/svnrdump/svnrdump.c
Author: hwright
Date: Wed Feb 1 02:15:57 2012
New Revision: 1238904
URL: http://svn.apache.org/viewvc?rev=1238904view=rev
Log:
More editor usage fixing in svnrdump. Provide a unique editor instance for
each revision, rather than reuse a single editor (which was a gross abuse of
the editor interface).
* subversion/svnrdump/svnrdump.c
(replay_baton): Store the output stream and backdoor ra session, rather an
an editor instance.
(replay_revstart): Provide a unique editor, rather than reuse an existing one.
(replay_revisions): Populate the baton members, and fetch a unique editor
for a special case.
Modified:
subversion/trunk/subversion/svnrdump/svnrdump.c
Modified: subversion/trunk/subversion/svnrdump/svnrdump.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/svnrdump/svnrdump.c?rev=1238904r1=1238903r2=1238904view=diff
==
--- subversion/trunk/subversion/svnrdump/svnrdump.c (original)
+++ subversion/trunk/subversion/svnrdump/svnrdump.c Wed Feb 1 02:15:57 2012
@@ -151,11 +151,11 @@ static const apr_getopt_option_t svnrdum
/* Baton for the RA replay session. */
struct replay_baton {
- /* The editor producing diffs. */
- const svn_delta_editor_t *editor;
+ /* A backdoor ra session for fetching information. */
+ svn_ra_session_t *extra_ra_session;
- /* Baton for the editor. */
- void *edit_baton;
+ /* The output stream */
+ svn_stream_t *stdout_stream;
/* Whether to be quiet. */
svn_boolean_t quiet;
@@ -220,10 +220,9 @@ replay_revstart(svn_revnum_t revision,
SVN_ERR(svn_stream_printf(stdout_stream, pool, \n));
SVN_ERR(svn_stream_close(stdout_stream));
- /* Extract editor and editor_baton from the replay_baton and
- set them so that the editor callbacks can use them. */
- *editor = rb-editor;
- *edit_baton = rb-edit_baton;
+ SVN_ERR(svn_rdump__get_dump_editor(editor, edit_baton, rb-stdout_stream,
+ rb-extra_ra_session, check_cancel,
+ NULL, pool));
return SVN_NO_ERROR;
}
@@ -354,21 +353,15 @@ replay_revisions(svn_ra_session_t *sessi
svn_boolean_t incremental,
apr_pool_t *pool)
{
- const svn_delta_editor_t *dump_editor;
struct replay_baton *replay_baton;
- void *dump_baton;
const char *uuid;
svn_stream_t *stdout_stream;
SVN_ERR(svn_stream_for_stdout(stdout_stream, pool));
- SVN_ERR(svn_rdump__get_dump_editor(dump_editor, dump_baton, stdout_stream,
- extra_ra_session, check_cancel, NULL,
- pool));
-
replay_baton = apr_pcalloc(pool, sizeof(*replay_baton));
- replay_baton-editor = dump_editor;
- replay_baton-edit_baton = dump_baton;
+ replay_baton-stdout_stream = stdout_stream;
+ replay_baton-extra_ra_session = extra_ra_session;
replay_baton-quiet = quiet;
/* Write the magic header and UUID */
@@ -406,6 +399,8 @@ replay_revisions(svn_ra_session_t *sessi
{
const svn_ra_reporter3_t *reporter;
void *report_baton;
+ const svn_delta_editor_t *dump_editor;
+ void *dump_baton;
/* First, we need to dump the start_revision in full. We'll
start with a revision record header. */
@@ -418,6 +413,9 @@ replay_revisions(svn_ra_session_t *sessi
to the update reporter, telling it that we have nothing to
start with. The delta between nothing and everything-at-REV
is, effectively, a full dump of REV. */
+ SVN_ERR(svn_rdump__get_dump_editor(dump_editor, dump_baton,
+ stdout_stream, extra_ra_session,
+ check_cancel, NULL, pool));
SVN_ERR(svn_ra_do_update2(session, reporter, report_baton,
start_revision, , svn_depth_infinity,
FALSE, dump_editor, dump_baton, pool));
svn commit: r1238923 - in /subversion/trunk/subversion/svnrdump: dump_editor.c svnrdump.c svnrdump.h
Author: hwright
Date: Wed Feb 1 03:31:05 2012
New Revision: 1238923
URL: http://svn.apache.org/viewvc?rev=1238923view=rev
Log:
Ev2 shims: Several improvements to the svnrdump code path, including accessing
the correct base revision and implementing kind fetching.
Current number of Ev2 test failures: 16
* subversion/svnrdump/dump_editor.c
(dump_edit_baton): Track the revision we're currently dumping.
(fetch_base_func): Use the proper base revision, if none is given.
(fetch_props_func): Fixup path, and use the proper base revision.
(fetch_kind_func): New.
(svn_rdump__get_dump_editor): Track the kind fetching function, as well as
the current revision.
* subversion/svnrdump/svnrdump.c
(replay_revstart, replay_revisions): Provide the current revision when
getting an editor.
(dump_cmd): Parent the extra ra session at the repos root.
* subversion/svnrdump/svnrdump.h
(svn_rdump__get_dump_editor): Add revision param.
Modified:
subversion/trunk/subversion/svnrdump/dump_editor.c
subversion/trunk/subversion/svnrdump/svnrdump.c
subversion/trunk/subversion/svnrdump/svnrdump.h
Modified: subversion/trunk/subversion/svnrdump/dump_editor.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/svnrdump/dump_editor.c?rev=1238923r1=1238922r2=1238923view=diff
==
--- subversion/trunk/subversion/svnrdump/dump_editor.c (original)
+++ subversion/trunk/subversion/svnrdump/dump_editor.c Wed Feb 1 03:31:05 2012
@@ -112,6 +112,9 @@ struct dump_edit_baton {
svn_boolean_t dump_text;
svn_boolean_t dump_props;
svn_boolean_t dump_newlines;
+
+ /* The revision we're currently dumping. */
+ svn_revnum_t current_revision;
};
/* Make a directory baton to represent the directory at PATH (relative
@@ -864,6 +867,9 @@ fetch_base_func(const char **filename,
if (path[0] == '/')
path += 1;
+ if (! SVN_IS_VALID_REVNUM(base_revision))
+base_revision = eb-current_revision - 1;
+
SVN_ERR(svn_stream_open_unique(fstream, filename, NULL,
svn_io_file_del_on_pool_cleanup,
result_pool, scratch_pool));
@@ -897,6 +903,12 @@ fetch_props_func(apr_hash_t **props,
struct dump_edit_baton *eb = baton;
svn_node_kind_t node_kind;
+ if (path[0] == '/')
+path += 1;
+
+ if (! SVN_IS_VALID_REVNUM(base_revision))
+base_revision = eb-current_revision - 1;
+
SVN_ERR(svn_ra_check_path(eb-ra_session, path, base_revision, node_kind,
scratch_pool));
@@ -925,9 +937,33 @@ fetch_props_func(apr_hash_t **props,
return SVN_NO_ERROR;
}
+static svn_error_t *
+fetch_kind_func(svn_kind_t *kind,
+void *baton,
+const char *path,
+svn_revnum_t base_revision,
+apr_pool_t *scratch_pool)
+{
+ struct dump_edit_baton *eb = baton;
+ svn_node_kind_t node_kind;
+
+ if (path[0] == '/')
+path += 1;
+
+ if (! SVN_IS_VALID_REVNUM(base_revision))
+base_revision = eb-current_revision - 1;
+
+ SVN_ERR(svn_ra_check_path(eb-ra_session, path, base_revision, node_kind,
+scratch_pool));
+
+ *kind = svn__kind_from_node_kind(node_kind, FALSE);
+ return SVN_NO_ERROR;
+}
+
svn_error_t *
svn_rdump__get_dump_editor(const svn_delta_editor_t **editor,
void **edit_baton,
+ svn_revnum_t revision,
svn_stream_t *stream,
svn_ra_session_t *ra_session,
svn_cancel_func_t cancel_func,
@@ -942,6 +978,7 @@ svn_rdump__get_dump_editor(const svn_del
eb = apr_pcalloc(pool, sizeof(struct dump_edit_baton));
eb-stream = stream;
eb-ra_session = ra_session;
+ eb-current_revision = revision;
/* Create a special per-revision pool */
eb-pool = svn_pool_create(pool);
@@ -976,6 +1013,7 @@ svn_rdump__get_dump_editor(const svn_del
shim_callbacks-fetch_base_func = fetch_base_func;
shim_callbacks-fetch_props_func = fetch_props_func;
+ shim_callbacks-fetch_kind_func = fetch_kind_func;
shim_callbacks-fetch_baton = eb;
SVN_ERR(svn_editor__insert_shims(editor, edit_baton, *editor, *edit_baton,
Modified: subversion/trunk/subversion/svnrdump/svnrdump.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/svnrdump/svnrdump.c?rev=1238923r1=1238922r2=1238923view=diff
==
--- subversion/trunk/subversion/svnrdump/svnrdump.c (original)
+++ subversion/trunk/subversion/svnrdump/svnrdump.c Wed Feb 1 03:31:05 2012
@@ -220,9 +220,9 @@ replay_revstart(svn_revnum_t revision,
SVN_ERR(svn_stream_printf(stdout_stream, pool, \n));
SVN_ERR(svn_stream_close(stdout_stream));
- SVN_ERR(svn_rdump__get_dump_editor(editor, edit_baton, rb-stdout_stream,
- rb-extra_ra_session, check_cancel,
svn commit: r1238931 - /subversion/trunk/subversion/include/svn_editor.h
Author: hwright Date: Wed Feb 1 03:50:40 2012 New Revision: 1238931 URL: http://svn.apache.org/viewvc?rev=1238931view=rev Log: * subversion/include/svn_editor.h (svn_editor_set_text): Add a question. Modified: subversion/trunk/subversion/include/svn_editor.h Modified: subversion/trunk/subversion/include/svn_editor.h URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_editor.h?rev=1238931r1=1238930r2=1238931view=diff == --- subversion/trunk/subversion/include/svn_editor.h (original) +++ subversion/trunk/subversion/include/svn_editor.h Wed Feb 1 03:50:40 2012 @@ -885,6 +885,7 @@ svn_editor_set_props(svn_editor_t *edito * with checksum @a checksum. * ### TODO @todo Does this send the *complete* content, always? * ### TODO @todo What is REVISION for? + * ### TODO @todo Who is responsible for closing the stream? * * For all restrictions on driving the editor, see #svn_editor_t. * @since New in 1.8.
svn commit: r1238932 - /subversion/trunk/subversion/libsvn_delta/compat.c
Author: hwright
Date: Wed Feb 1 04:35:54 2012
New Revision: 1238932
URL: http://svn.apache.org/viewvc?rev=1238932view=rev
Log:
Ev2 shims: Pass the checksum of the resulting file through the close_file()
interface.
Current number of Ev2 test failures: 15
* subversion/libsvn_delta/compat.c
(operation): Add new checksum member.
(build): Accept a checksum, and store it in the operation.
(add_directory_cb, add_symlink_cb, add_absent_cb, set_props_cb, delete_cb,
copy_cb): Update callers.
(add_file_cb, set_text_cb): Make sure we have the correct checksum and store
it for use with close_file().
(drive_tree): Pass the checksum to close_file().
Modified:
subversion/trunk/subversion/libsvn_delta/compat.c
Modified: subversion/trunk/subversion/libsvn_delta/compat.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_delta/compat.c?rev=1238932r1=1238931r2=1238932view=diff
==
--- subversion/trunk/subversion/libsvn_delta/compat.c (original)
+++ subversion/trunk/subversion/libsvn_delta/compat.c Wed Feb 1 04:35:54 2012
@@ -937,6 +937,7 @@ struct operation {
svn_kind_t kind; /* to copy, mkdir, put or set revprops */
svn_revnum_t base_revision; /* When committing, the base revision */
svn_revnum_t copyfrom_revision; /* to copy, valid for add and replace */
+ svn_checksum_t *new_checksum; /* An MD5 hash of the new contents, if any */
const char *copyfrom_url; /* to copy, valid for add and replace */
const char *src_file; /* for put, the source file for contents */
apr_hash_t *children; /* const char *path - struct operation * */
@@ -1024,6 +1025,7 @@ build(struct editor_baton *eb,
svn_revnum_t rev,
apr_hash_t *props,
const char *src_file,
+ svn_checksum_t *checksum,
svn_revnum_t head,
apr_pool_t *scratch_pool)
{
@@ -1149,7 +1151,8 @@ build(struct editor_baton *eb,
'%s' is not a file, relpath);
}
operation-kind = svn_kind_file;
- operation-src_file = src_file;
+ operation-src_file = apr_pstrdup(eb-edit_pool, src_file);
+ operation-new_checksum = svn_checksum_dup(checksum, eb-edit_pool);
}
else
{
@@ -1177,17 +1180,17 @@ add_directory_cb(void *baton,
SVN_ERR(build(eb, ACTION_DELETE, relpath, svn_kind_unknown,
NULL, SVN_INVALID_REVNUM,
-NULL, NULL, SVN_INVALID_REVNUM, scratch_pool));
+NULL, NULL, NULL, SVN_INVALID_REVNUM, scratch_pool));
}
SVN_ERR(build(eb, ACTION_MKDIR, relpath, svn_kind_dir,
NULL, SVN_INVALID_REVNUM,
-NULL, NULL, SVN_INVALID_REVNUM, scratch_pool));
+NULL, NULL, NULL, SVN_INVALID_REVNUM, scratch_pool));
if (props apr_hash_count(props) 0)
SVN_ERR(build(eb, ACTION_PROPSET, relpath, svn_kind_dir,
NULL, SVN_INVALID_REVNUM, props,
- NULL, SVN_INVALID_REVNUM, scratch_pool));
+ NULL, NULL, SVN_INVALID_REVNUM, scratch_pool));
return SVN_NO_ERROR;
}
@@ -1205,6 +1208,14 @@ add_file_cb(void *baton,
struct editor_baton *eb = baton;
const char *tmp_filename;
svn_stream_t *tmp_stream;
+ svn_checksum_t *md5_checksum;
+
+ /* We may need to re-checksum these contents */
+ if (!(checksum checksum-kind == svn_checksum_md5))
+contents = svn_stream_checksummed2(contents, md5_checksum, NULL,
+ svn_checksum_md5, TRUE, scratch_pool);
+ else
+md5_checksum = (svn_checksum_t *)checksum;
if (SVN_IS_VALID_REVNUM(replaces_rev))
{
@@ -1212,24 +1223,24 @@ add_file_cb(void *baton,
SVN_ERR(build(eb, ACTION_DELETE, relpath, svn_kind_unknown,
NULL, SVN_INVALID_REVNUM,
-NULL, NULL, SVN_INVALID_REVNUM, scratch_pool));
+NULL, NULL, NULL, SVN_INVALID_REVNUM, scratch_pool));
}
/* Spool the contents to a tempfile, and provide that to the driver. */
SVN_ERR(svn_stream_open_unique(tmp_stream, tmp_filename, NULL,
svn_io_file_del_on_pool_cleanup,
eb-edit_pool, scratch_pool));
- SVN_ERR(svn_stream_copy3(svn_stream_disown(contents, scratch_pool),
- tmp_stream, NULL, NULL, scratch_pool));
+ SVN_ERR(svn_stream_copy3(contents, tmp_stream, NULL, NULL, scratch_pool));
SVN_ERR(build(eb, ACTION_PUT, relpath, svn_kind_none,
NULL, SVN_INVALID_REVNUM,
-NULL, tmp_filename, SVN_INVALID_REVNUM, scratch_pool));
+NULL, tmp_filename, md5_checksum, SVN_INVALID_REVNUM,
+scratch_pool));
if (props apr_hash_count(props) 0)
SVN_ERR(build(eb, ACTION_PROPSET, relpath, svn_kind_file,
NULL, SVN_INVALID_REVNUM, props,
- NULL, SVN_INVALID_REVNUM,
Re: svn commit: r1238862 - /subversion/trunk/subversion/svnrdump/dump_editor.c
hwri...@apache.org wrote on Tue, Jan 31, 2012 at 23:40:06 -:
Author: hwright
Date: Tue Jan 31 23:40:06 2012
New Revision: 1238862
URL: http://svn.apache.org/viewvc?rev=1238862view=rev
Log:
Ev2 shims: Add a prop fetching function for svnrdump. This prevents crashes,
but doesn't improve any correctness--yet.
* subversion/svnrdump/dump_editor.c
(fetch_props_func): New.
(svn_rdump__get_dump_editor): Use the prop fetching function.
Modified:
subversion/trunk/subversion/svnrdump/dump_editor.c
Modified: subversion/trunk/subversion/svnrdump/dump_editor.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/svnrdump/dump_editor.c?rev=1238862r1=1238861r2=1238862view=diff
==
--- subversion/trunk/subversion/svnrdump/dump_editor.c (original)
+++ subversion/trunk/subversion/svnrdump/dump_editor.c Tue Jan 31 23:40:06
2012
@@ -886,6 +886,45 @@ fetch_base_func(const char **filename,
return SVN_NO_ERROR;
}
+static svn_error_t *
+fetch_props_func(apr_hash_t **props,
+ void *baton,
+ const char *path,
+ svn_revnum_t base_revision,
+ apr_pool_t *result_pool,
+ apr_pool_t *scratch_pool)
+{
+ struct dump_edit_baton *eb = baton;
+ svn_node_kind_t node_kind;
+
+ SVN_ERR(svn_ra_check_path(eb-ra_session, path, base_revision, node_kind,
+scratch_pool));
+
+ if (node_kind == svn_node_file)
+{
+ SVN_ERR(svn_ra_get_file(eb-ra_session, path, base_revision,
+ NULL, NULL, props, result_pool));
+}
+ else if (node_kind == svn_node_dir)
+{
+ apr_array_header_t *tmp_props;
+
+ SVN_ERR(svn_ra_get_dir2(eb-ra_session, NULL, NULL, props, path,
+ base_revision, 0 /* Dirent fields */,
+ result_pool));
+ tmp_props = svn_prop_hash_to_array(*props, result_pool);
+ SVN_ERR(svn_categorize_props(tmp_props, NULL, NULL, tmp_props,
+ result_pool));
+ *props = svn_prop_array_to_hash(tmp_props, result_pool);
+}
+ else
+{
+ *props = apr_hash_make(result_pool);
Is it correct to return an empty hash for svn_node_unknown?
+}
+
+ return SVN_NO_ERROR;
+}
