Am 24.04.2012 16:32, schrieb Julian Foad:
Paul Burba wrote:
On Fri, Apr 20, 2012 at 6:17 AM, Julian Foad wrote:
I see there's already a brief statement about sparse WCs too:
<http://svn.apache.org/repos/asf/subversion/trunk/notes/merge-tracking/func-spec.html#sparse-checkouts>.
I'm not clear how the whole 'depth' thing works, though, if you add
children to a directory that was initially sparse or exclude children
from a directory that was initially depth non-empty.
Ah, welcome to my world! [...]
Where it gets whacky is if the merge *adds* paths which are
immediate children of the children currently present (e.g. merge
target at depth empty, merge adds a immediate file to the merge
target). Today we add the file, despite the fact that the target's
depth is empty.
Before you claw your eyes out in frustration, read the issue I just
filed: http://subversion.tigris.org/issues/show_bug.cgi?id=4164 It
spells out the problem fairly clearly (I hope!).
The sparse-directories design<notes/sparse-directories.txt> doesn't seem to
indicate the intended behaviour when update brings in a new child. I've added a note
about that to the end of that document.
It seems that the problem is not *how* to make merge behave the right way to be
compatible with sparse directories, but that we haven't decided what the Right
Way is.
Observation on my part: I think it is ironic that a
centralized VCS tries to do de-centralized merges
with all the missing information and special cases
that it has to allow for on the client side. Those
special cases stem from features that you need to
have (sparse wc, mixed revs) as long as you want
to have client-side WCs.
Maybe, the "right way" to do merges would be
server-side merges. But I'm not advocating to put
any effort into that right away ;)
Stefan Fuhrmann wrote:
Am 19.04.2012 18:57, schrieb Julian Foad:
FWIW, I have an inkling of how a mixed-rev target WC should work [...]
That said, I can't imagine any valid reason to need to support a
mixed-rev target WC.
Well, in the end one will always commit against HEAD.
But there are two use-cases of different importance
that should be supported:
* A WC is usually not at HEAD because commits don't
update unchanged nodes. On branches, the WC will
often contain the latest changes as few people work
on that branch. A WC of /trunk can be expected to be
outdated even if it was updated to HEAD shortly before
the merge.
Those are some valid observations. Note that your third point doesn't result
in a mixed-rev WC. But it's not a big deal to ask the user to 'svn up' before
merging, so it's not obvious that any of these situations mean we need to
support merging into the WC without an update first. (Of course I acknowledge
that it would be *easier* for the user, if it doesn't cause other problems.)
For experience with large working copies, I would not
want SVN to ask me to update to HEAD whenever I
happen to fall behind. It is a nuisance already that I
often have to update before I can commit the merge
because SVN would not allow to modify the directory
properties (svn:merge-info) without the directory
content being up-to-date.
The issue with large working copies is clearly the time
factor: Non-merging users can commit quickly, i.e. often.
A merging user needs to update the whole WC and then
try to commit.
* Mixed-rev working copies are an intermediate step
in creating arbitrary configurations via 'svn cp WC URL'.
Merging into the copy target should be semantically
identical to merging into a mixed-rev WC.
Yes, I agree.
I have thought very little about about how switched subtrees should work.
However, I *can* imagine scenarios where the user has a large chunk of WC
switched, and now wants to merge something into the whole WC knowing that
it won't in fact touch the switched part. That seems like a reasonable
thing to support: untouched paths being switched. I haven't yet thought
of a use case for switched paths that are touched by the merge.
We could even be more permissive: as long as the merge
does not cross "switch boundaries" (switched / non-
switched or switched to different URL) as may allow
the merge.
Let's say A/B is switched relative to A.
You mean a merge where the specified target is A/B should succeed? Yes,
I agree with that, and that's already documented in
<http://svn.apache.org/repos/asf/subversion/trunk/notes/merge-tracking/func-spec.html#switched-paths>.
At first I thought you meant a merge where the specified target is A
could be allowed to succeed if it only touched paths inside A/B. That
doesn't seem like a good idea.
OK.
This could be a somewhat typical use-case for people
using switched WCs. I would expect that these users
want to merge into those sub-trees just like they
would also 'svn up' them.
One thing is clear: this whole discussion is evidence that the way merging
should work in a
WC with sparse directories, mixed revisions and/or switched subtrees is not
exactly clear. I accept that we have existing behaviour as precedent for the
common cases, as well as somne level of rationale; I'm not trying to say we
have no idea at all.
Same feeling here. SvnDay @Berlin would be an excellent opportunity
to discuss some these more fundamental questions.
As I'm writing this, I'm on my way to Antalya where I can discuss
with Cristian and Andy directly which concrete improvements
can be made right now. For the time being, I would like to focus
on the rename tracking part and support testing efforts. I would
expect that to minimize the coordination overhead.
-- Stefan^2.
