You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Markus Schaber <m....@3s-software.com> on 2011/08/18 16:54:15 UTC
Tree Conflicts with Subversion 1.7
Hi,
Can Subversion 1.7 still have tree conflicts?
Or can the new working copy break them down to individual conflicts on
files (and directory properties)?
Best regards
Markus Schaber
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Tree Conflicts with Subversion 1.7
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stein Somers wrote on Thu, Aug 18, 2011 at 20:41:44 +0200:
> On 18-Aug-11 19:05, Daniel Shahaf wrote:
> >What copyfrom would the single directory have, in the case of an add/add
> >conflict?
>
> The same as if you resolve an add/add file conflict by manually
> throwing the two file contents into one file: you may wish a double
> copyfrom, to trace back to both origins later. I bet our beloved SVN
> developers are not eager to support multiple copyfroms, so at most
> one of them gets the honor.
You don't sound like you care to have a technical discussion about the
problems that multiple copyfrom would introduce v. would solve.
Re: Merge symmetry (was: Tree Conflicts with Subversion 1.7)
Posted by Andreas Krey <a....@gmx.de>.
On Mon, 22 Aug 2011 14:36:36 +0000, Stefan Sperling wrote:
...
> In Subversion, a merge is the computation of a delta between two
> arbitary trees, and the application of this delta to some other
> arbitrary tree.
To keep the (vector) addition analogy, you are measuring the difference
from A to B and move C in this direction. Which yields the same as
measuring from A to C and move B in *that* direction. You end up in the
same point. Just once B ends up there, and once C.
Anyway, while that is what you tell, and probably do for directories,
you can't get around using a version of the (symmetrical) diff3 to merge
file contents; that is the only way to sanely apply the delta. An actual
delta (patch) wouldn't generally be applicable to the target file.
> The merge target is *completely independent* of the merge delta.
> There is nothing, in the core algorithm, that would know about stuff
> like merge points and the like.
No, that comes into play when selecting the two revisions and paths that
you need to compute the delta to apply.
> You seem to be basing your mental
> model of merge on tools like git or hg. And that is a very good model.
> But it is very different from what Subversion is doing.
Unfortunately it is not that different from what I expected when
subversion was said to get proper merge support. (I was pampered
by cvsnt, which (once) could do bidirectional merges.)
> There is no merge DAG in Subversion.
> The closest equivalent to a merge DAG is svn:mergeinfo, but it
> doesn't implement a DAG -- it implements a filter that prevents
> the same revisions from being merged twice. That's all.
And unfortunately, it is so simplistic that you need to prod it with
--reintegrate the first (and last) time you merge in the other direction.
(Or it seems so.)
> It is really quite simple at the design level. The implementation
> is not simple because it handles a lot of additional quirks that
> are not reflected in this short and abstract description of what
> Subversion is doing.
Yes, recorded cherrypicking, not to mention all the rename handling.
...
> Let me quote the relevant part of the post I linked to:
...
> Is that clear enough? If not, please ask.
It's not quite. But it seems I need to wade through what actually happens
with the mergeinfo to understand why a backmerge can't deduce the proper
action without --reintegrate, and why the merge info then needs to be
borken for the branch. (Which may be partly simply because you can't
modify the branch's mergeinfo to mark the merge revision on the trunk
as already merged.)
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Merge symmetry (was: Tree Conflicts with Subversion 1.7)
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Aug 22, 2011 at 01:49:45PM +0200, Andreas Krey wrote:
> On Mon, 22 Aug 2011 12:38:40 +0000, Stefan Sperling wrote:
> > On Fri, Aug 19, 2011 at 04:15:38PM +0200, Andreas Krey wrote:
> ...
> > > Actually, merging is a symmetric operation. The tree (and copyfrom
> > > info) resulting from a merge should be the same independent of in
> > > which direction the merge is performed.
> >
> > I agree that symmetry is a nice-to-have property of a merge algorithm.
>
> I actually think it is essential.
>
> > But I would be totally happy with asymmetric results, as long as either
> > result is well-defined and repeatable. I don't see why the behaviour
> > of a merge algorithm must be symmetric.
>
> Because a merge computes the addition of two changesets/diffs/however you
> name that: The delta from branch point (or last merge point) to trunk,
> and to branch head. I see no reason why the outcome should depend on
> which side I choose as the base of the merge: addition is commutative.
Because that's not how Subversion works.
In Subversion, a merge is the computation of a delta between two
arbitary trees, and the application of this delta to some other
arbitrary tree.
The merge target is *completely independent* of the merge delta.
There is nothing, in the core algorithm, that would know about stuff
like merge points and the like. You seem to be basing your mental
model of merge on tools like git or hg. And that is a very good model.
But it is very different from what Subversion is doing.
There is no merge DAG in Subversion.
The closest equivalent to a merge DAG is svn:mergeinfo, but it
doesn't implement a DAG -- it implements a filter that prevents
the same revisions from being merged twice. That's all.
It is really quite simple at the design level. The implementation
is not simple because it handles a lot of additional quirks that
are not reflected in this short and abstract description of what
Subversion is doing.
> > Sounds like you are conflating the UI with the underlying design.
>
> No, I meant that besides the symmetry issue svn the mergeinfo actually
> encode different information depending on the direction of the merge.
Yes, that's true.
> > --reintegrate is a UI issue and has nothing to do with symmetry
> > or correctness.
>
> I still don't quite understand why exactly --reintegrate is necessary.
>
> Is it just because 'svn merge ^/branch' once meant 'take all changes of
> branch since the branch point and merge them into trunk', and it shall
> still mean that so we need --reintegrate to look closer onto the merge
> info to use the source of the last sync merge instead of the branch
> point as merge base? (But then we would need a 'merge --sync' as well.)
>
> If it's not that, I don't see how the necessity of --reintegrate is an
> UI issue and not a result of a suboptimal mergeinfo design, along with
> the deadness of a branch after reintegration.
Let me quote the relevant part of the post I linked to:
[[[
Essentially, all merges in Subversion are 2-URL merges.
svn merge generates some delta and applies that to a working copy.
There is no other way, right now, that a merge could work.
A two-URL merge needs the following parameters:
PATH1, REV1 (left side of the delta)
PATH2, REV2 (right side of the delta)
TARGET (working copy of some PATH3, up-to-date enough for commit)
The reintegrate merge automatically fills in all required parameters
expect PATH2, and we get:
PATH1 = trunk, REV1 = rX
PATH2 = feature, REV2 = HEAD
TARGET = working copy of trunk (generally speaking @HEAD)
A sync merge can fill in the all parameters as well, except PATH2.
However, it needs to do so in a different way. With a sync merge
PATH1 and PATH2 are the same so the delta between trunk@REV1 and
trunk@REV2 is merged into a working copy of the feature branch
In case of reintegrate PATH1 and PATH2 are not the same!
So svn merge needs the special --reintegrate option because just
'svn merge ^/branch' would be ambiguous.
]]]
Is that clear enough? If not, please ask.
Re: Merge symmetry (was: Tree Conflicts with Subversion 1.7)
Posted by Andreas Krey <a....@gmx.de>.
On Mon, 22 Aug 2011 12:38:40 +0000, Stefan Sperling wrote:
> On Fri, Aug 19, 2011 at 04:15:38PM +0200, Andreas Krey wrote:
...
> > Actually, merging is a symmetric operation. The tree (and copyfrom
> > info) resulting from a merge should be the same independent of in
> > which direction the merge is performed.
>
> I agree that symmetry is a nice-to-have property of a merge algorithm.
I actually think it is essential.
> But I would be totally happy with asymmetric results, as long as either
> result is well-defined and repeatable. I don't see why the behaviour
> of a merge algorithm must be symmetric.
Because a merge computes the addition of two changesets/diffs/however you
name that: The delta from branch point (or last merge point) to trunk,
and to branch head. I see no reason why the outcome should depend on
which side I choose as the base of the merge: addition is commutative.
Although the 'addition' part may be seen as wordplay, I'd like to see
a case where a merge could reasonably not be symmetric (barring cases
with conflicts, where the conflict presentation usually is unsymmetric).
> > In svn the metadata just looks
> > completely different depending on the direction of the merge. (It also
> > is different due to the necessity of --reintegrate.)
>
> Sounds like you are conflating the UI with the underlying design.
No, I meant that besides the symmetry issue svn the mergeinfo actually
encode different information depending on the direction of the merge.
> --reintegrate is a UI issue and has nothing to do with symmetry
> or correctness.
I still don't quite understand why exactly --reintegrate is necessary.
Is it just because 'svn merge ^/branch' once meant 'take all changes of
branch since the branch point and merge them into trunk', and it shall
still mean that so we need --reintegrate to look closer onto the merge
info to use the source of the last sync merge instead of the branch
point as merge base? (But then we would need a 'merge --sync' as well.)
If it's not that, I don't see how the necessity of --reintegrate is an
UI issue and not a result of a suboptimal mergeinfo design, along with
the deadness of a branch after reintegration.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Merge symmetry (was: Tree Conflicts with Subversion 1.7)
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Aug 19, 2011 at 04:15:38PM +0200, Andreas Krey wrote:
> On Fri, 19 Aug 2011 13:51:40 +0000, Stein Somers wrote:
>
> > Now I realize merges are always asymmetric.
>
> Actually, merging is a symmetric operation. The tree (and copyfrom
> info) resulting from a merge should be the same independent of in
> which direction the merge is performed.
I agree that symmetry is a nice-to-have property of a merge algorithm.
But I would be totally happy with asymmetric results, as long as either
result is well-defined and repeatable. I don't see why the behaviour
of a merge algorithm must be symmetric.
> In svn the metadata just looks
> completely different depending on the direction of the merge. (It also
> is different due to the necessity of --reintegrate.)
Sounds like you are conflating the UI with the underlying design.
--reintegrate is a UI issue and has nothing to do with symmetry
or correctness.
See http://mail-archives.apache.org/mod_mbox/subversion-dev/201107.mbox/%3C20110720124721.GA7557@ted.stsp.name%3E
Merge symmetry (was: Tree Conflicts with Subversion 1.7)
Posted by Andreas Krey <a....@gmx.de>.
On Fri, 19 Aug 2011 13:51:40 +0000, Stein Somers wrote:
> Now I realize merges are always asymmetric.
Actually, merging is a symmetric operation. The tree (and copyfrom
info) resulting from a merge should be the same independent of in
which direction the merge is performed. In svn the metadata just looks
completely different depending on the direction of the merge. (It also
is different due to the necessity of --reintegrate.)
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Tree Conflicts with Subversion 1.7
Posted by Stein Somers <ss...@opnet.com>.
On 18-Aug-11 21:01, Stefan Sperling wrote:
> Indeed, multiple copyfroms would be nasty.
>
> But I don't see the need.
I definitely don't need it, I just saw a use in having it.
My idea that you should be able to choose the source was based on a wrong
assumption. Now I realize merges are always asymmetric. Usually you commit a
merge of branches A and B as a changeset in either A or B, but even if you
commit as branch C, that changeset still starts off saying C is a copy of either
A or B, with some more changes to it (right?). You always have to choose A or B,
and you call one "local" and the other one "incoming" (by the way, I like those
terms a lot better than the "mine" and "theirs" used in the interface - they
freak me out when I merge "my" branch into "our" trunk).
That doesn't mean there is no case for wanting multiple copyfroms, if that is
what Daniel Shahaf hints at, but just that the fact that "local" is favored is
firmly part of svn's merge philosophy anyway, and I have no problem with that.
--
Stein
Re: Tree Conflicts with Subversion 1.7
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Aug 18, 2011 at 08:41:44PM +0200, Stein Somers wrote:
> On 18-Aug-11 19:05, Daniel Shahaf wrote:
> >What copyfrom would the single directory have, in the case of an add/add
> >conflict?
>
> The same as if you resolve an add/add file conflict by manually
> throwing the two file contents into one file: you may wish a double
> copyfrom, to trace back to both origins later. I bet our beloved SVN
> developers are not eager to support multiple copyfroms, so at most
> one of them gets the honor.
Indeed, multiple copyfroms would be nasty.
But I don't see the need. Because, ideally, copyfrom info should always point
to a node in the same branch, even if the copy was merged from another branch.
> To be accurate, the first add/add resolution strategy has three subplots:
> - put all files in the same directory ("Markus Schaber's strategy")
> - and pretend it's a copy from local
> - and pretend it's a copy from incoming
> - and pretend it's brand new
I think a copy source should always be from the local branch, or an add if
no suitable copy source node exists in the local branch. The copy source
will exist, at least it the branch's history, if the branches have common
ancestry and all revisions are merged (i.e. no cherry-picking).
But it won't exist in all cases. Hence the current strategy of having
the copyfrom point to the merge source. It is an easy way out but I
don't like it. It is the most reasonable thing to do if you don't want
to worry about copy sources that don't exist, but it's quite stupid and
non-intuitive at the semantic level.
> In any case, even if there was an automatic add/add resolution for
> directories, it's still possible to have an add/add conflict of a
> directory versus a file, and I dare Markus to come up with an
> automatic resolution for that...
Agreed. The tool should not try to outsmart people in complicated
cases like this. Whenever there is more than one option to resolve
a conflict, all options should be offered.
Re: Tree Conflicts with Subversion 1.7
Posted by Stein Somers <ss...@opnet.com>.
On 18-Aug-11 19:05, Daniel Shahaf wrote:
> What copyfrom would the single directory have, in the case of an add/add
> conflict?
The same as if you resolve an add/add file conflict by manually throwing the two
file contents into one file: you may wish a double copyfrom, to trace back to
both origins later. I bet our beloved SVN developers are not eager to support
multiple copyfroms, so at most one of them gets the honor.
To be accurate, the first add/add resolution strategy has three subplots:
- put all files in the same directory ("Markus Schaber's strategy")
- and pretend it's a copy from local
- and pretend it's a copy from incoming
- and pretend it's brand new
In any case, even if there was an automatic add/add resolution for directories,
it's still possible to have an add/add conflict of a directory versus a file,
and I dare Markus to come up with an automatic resolution for that...
--
Stein
Re: Tree Conflicts with Subversion 1.7
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Markus Schaber wrote on Thu, Aug 18, 2011 at 17:30:59 +0200:
> Hi,
>
>
> Von: Stefan Sperling [mailto:stsp@elego.de]
> > On Thu, Aug 18, 2011 at 04:54:15PM +0200, Markus Schaber wrote:
> > > Hi,
> > >
> > > Can Subversion 1.7 still have tree conflicts?
> >
> > Yes. Nothing much has changed on that front for 1.7.
> > Foundations for some bigger changes in tree-conflict behaviour planned
> for
> > 1.8 and later are already being worked on.
> >
> > > Or can the new working copy break them down to individual conflicts
> on
> > > files (and directory properties)?
> >
> > Not sure what you mean here. Can you provide an example?
>
> My idea was that directories itsself would never conflict. If there's a
> directory removed, and a new one created with the same name, it is the
> same directory, so no tree conflict. If the directories have different
> properties, then those properties conflict, and if they have conflicting
> files, then those files conflict individually. But no tree conflict.
>
> But maybe my thought is a little bit to short.
What copyfrom would the single directory have, in the case of an add/add
conflict?
% svn mkdir A; svn ci -m r1
% svn rm A; svn ci -m r2
% svn mkdir A
% svn merge -c1 ./
Re: Tree Conflicts with Subversion 1.7
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Aug 22, 2011 at 01:59:45PM +0200, Andreas Krey wrote:
> It's not bug-worthy. AFAIR, when I (p) a property conflict, I get
> the conflict markers into the property, and at least 'svn diff' does
> not believe that properties (esp. svn:externals) may be multi-line,
> and AFAIR you also just get both versions as a full-file conflict
> in the property value. Doesn't make exactly easy to see what happened.
> (I may also mingle this up with a property conflict after a regular 'svn up'.)
>
> But as I unterstand, at least the multi-line property diffing is going to
> get better.
Yes, this problem has been fixed in 1.7.
http://subversion.apache.org/docs/release-notes/1.7.html#diff-properties
> And you think I can't open a new shell or ^Z the merge?
Of course you can. You can also walk away from the screen and let
it sit there until the connection times out :)
> It would be
> seriously annoying if the merge then died on a timeout (which it may
> just as well on the (e), which incidentally indirectly allows me to
> spawn a shell).
Well, that's what happens right now. I agree that it isn't ideal.
Re: Tree Conflicts with Subversion 1.7
Posted by Andreas Krey <a....@gmx.de>.
On Mon, 22 Aug 2011 12:49:25 +0000, Stefan Sperling wrote:
...
> > I'm used to manual merges, which means its always (p) with me. Which
> > unfortunately does not work quite well with properties, as far I
> > remember.
>
> Can you provide details? What doesn't work, exactly?
> Is there already an issue filed for this problem?
It's not bug-worthy. AFAIR, when I (p) a property conflict, I get
the conflict markers into the property, and at least 'svn diff' does
not believe that properties (esp. svn:externals) may be multi-line,
and AFAIR you also just get both versions as a full-file conflict
in the property value. Doesn't make exactly easy to see what happened.
(I may also mingle this up with a property conflict after a regular 'svn up'.)
But as I unterstand, at least the multi-line property diffing is going to
get better.
...
> > One thing that would be helpful is (!): Run a shell.
>
> I agree that would be nice.
>
> However, right now, svn opens the prompt while the TCP connection
> to the server is still open.
And you think I can't open a new shell or ^Z the merge? It would be
seriously annoying if the merge then died on a timeout (which it may
just as well on the (e), which incidentally indirectly allows me to
spawn a shell).
...
> It's not going to be mandatory. It will be an optional helper,
> just like the current interactive conflict resolution prompt.
Good. Even the presentation of what exactly will be committed will
be interesting.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Tree Conflicts with Subversion 1.7
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Aug 19, 2011 at 12:20:56PM +0200, Andreas Krey wrote:
> On Thu, 18 Aug 2011 20:46:51 +0000, Stefan Sperling wrote:
> ...
> > > Actually I think these are better handled by throwing away the merge
> > > results and doing the renames/removes on the respective branches, then
> > > redo the merge.
> >
> > The above is only for "add vs. add" situations.
> > Scenarios involving renames are different.
>
> I meant when I get an add/add conflict on unrelated directories
> (or files), I'd undo the merge, rename one of the directories in the
> respective branch and retry the merge.
OK. In this case it should auto-resolve the conflict (it does not as
of now, of course, but it will eventually).
> Offhand, I wouldn't know where
> subversion would place the unrelated versions of the directories in the
> sandbox, nor how I could tell it that I want one of those kept in the
> merge result (with same or different name).
We cannot store the tree anywhere right now.
But we can create some space in the new meta-data store.
> > > I tend to feel uneasy in these interactive conflict resolutions.
> >
> > What makes you feel uneasy about it?
>
> I'm used to manual merges, which means its always (p) with me. Which
> unfortunately does not work quite well with properties, as far I
> remember.
Can you provide details? What doesn't work, exactly?
Is there already an issue filed for this problem?
> (And (e) gives me 'EDITOR not set' even though it is offered.)
Hmmm... does it not ask for an editor command to run?
That's the least it could do.
> One thing that would be helpful is (!): Run a shell.
I agree that would be nice.
However, right now, svn opens the prompt while the TCP connection
to the server is still open.
We need to change this so that svn first downloads all required data,
and then runs the interactive prompt
(bug: http://subversion.tigris.org/issues/show_bug.cgi?id=3846).
Then we have all time in the world and might as well spawn a shell.
> > Note that, ideally, this menu could be recalled offline, after the
> > merge/update has completed with all conflicts postponed.
> > So you'd have all the time in the world to figure out your answer,
> > if that's what worrying you.
>
> The problem is more like it is another tool which you hopefully never
> need, yet need to know well if you do.
It's not going to be mandatory. It will be an optional helper,
just like the current interactive conflict resolution prompt.
Re: Tree Conflicts with Subversion 1.7
Posted by Andreas Krey <a....@gmx.de>.
On Thu, 18 Aug 2011 20:46:51 +0000, Stefan Sperling wrote:
...
> > Actually I think these are better handled by throwing away the merge
> > results and doing the renames/removes on the respective branches, then
> > redo the merge.
>
> The above is only for "add vs. add" situations.
> Scenarios involving renames are different.
I meant when I get an add/add conflict on unrelated directories
(or files), I'd undo the merge, rename one of the directories in the
respective branch and retry the merge. Offhand, I wouldn't know where
subversion would place the unrelated versions of the directories in the
sandbox, nor how I could tell it that I want one of those kept in the
merge result (with same or different name).
> > I tend to feel uneasy in these interactive conflict resolutions.
>
> What makes you feel uneasy about it?
I'm used to manual merges, which means its always (p) with me. Which
unfortunately does not work quite well with properties, as far I
remember. (And (e) gives me 'EDITOR not set' even though it is
offered.) One thing that would be helpful is (!): Run a shell.
And in the interactive mode it's one file after another; I can't
compile well in between. (I was lucky enough not to have actual
tree conflicts yet.)
> Note that, ideally, this menu could be recalled offline, after the
> merge/update has completed with all conflicts postponed.
> So you'd have all the time in the world to figure out your answer,
> if that's what worrying you.
The problem is more like it is another tool which you hopefully never
need, yet need to know well if you do.
Just the display of what has been done so far ('dir from branch will
commit as newdir') is going to be interesting.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Tree Conflicts with Subversion 1.7
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Aug 18, 2011 at 07:22:28PM +0200, Andreas Krey wrote:
> On Thu, 18 Aug 2011 18:13:09 +0000, Stefan Sperling wrote:
> ...
> > But I don't think subversion should enforce one particular merge outcome.
> > My opinion is that the user should be given a choice, and be supported
> > by an interactive conflict resolution prompt that shows all possible
> > resolution strategies:
> > - put all files in the same directory ("Markus Schaber's strategy")
> > - rename the local directory
> > - rename the incoming directory
> > - delete the local directory, replace with incoming directory
> > - discard the incoming directory, keep the local directory
> > - discard both directories
>
> Actually I think these are better handled by throwing away the merge
> results and doing the renames/removes on the respective branches, then
> redo the merge.
The above is only for "add vs. add" situations.
Scenarios involving renames are different.
> I tend to feel uneasy in these interactive conflict resolutions.
What makes you feel uneasy about it?
Note that, ideally, this menu could be recalled offline, after the
merge/update has completed with all conflicts postponed.
So you'd have all the time in the world to figure out your answer,
if that's what worrying you.
Re: Tree Conflicts with Subversion 1.7
Posted by Andreas Krey <a....@gmx.de>.
On Thu, 18 Aug 2011 18:13:09 +0000, Stefan Sperling wrote:
...
> But I don't think subversion should enforce one particular merge outcome.
> My opinion is that the user should be given a choice, and be supported
> by an interactive conflict resolution prompt that shows all possible
> resolution strategies:
> - put all files in the same directory ("Markus Schaber's strategy")
> - rename the local directory
> - rename the incoming directory
> - delete the local directory, replace with incoming directory
> - discard the incoming directory, keep the local directory
> - discard both directories
Actually I think these are better handled by throwing away the merge
results and doing the renames/removes on the respective branches, then
redo the merge. I tend to feel uneasy in these interactive conflict
resolutions.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Tree Conflicts with Subversion 1.7
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Aug 18, 2011 at 05:30:59PM +0200, Markus Schaber wrote:
> My idea was that directories itsself would never conflict. If there's a
> directory removed, and a new one created with the same name, it is the
> same directory, so no tree conflict. If the directories have different
> properties, then those properties conflict, and if they have conflicting
> files, then those files conflict individually. But no tree conflict.
>
> But maybe my thought is a little bit to short.
Depending on what the directories represent, this may or may not
be desirable.
Consider this example:
Two Java developers, Harry and Sally, work on different feature
branches A and B. The code base they're working on is a sales
and purchase tracking system.
Harry creates a new package called 'fruit' on branch A, which
contains classes for tracking fruit sales.
Sally creates a new package called 'fruit' on branch B, which
contains classes for tracking fruit purchases.
Both packages do serve entirely different purposes but happen to share
the same name (of course, the example hinges on the fact that there are
no subpackages which devide packages between the 'sales' and 'purchase'
categories -- but things like this do happen in real life).
Feature branch A gets merged into trunk.
Feature branch B gets merged into trunk. Now there is a tree conflict.
If we simply throw both sets of files in the different 'fruit' packages
together into a single 'fruit' directory, Sally will have a lot of fun
sorting the individual files back into different directories.
Note that this is how git, Mercurial, and maybe others behave in this
situation.
Right now, Subversion simply flags a conflict and lets the user resolve
the situation in the working copy. This is a crude user-interface but it
covers all possible resolution strategies, assuming the user knows how
to achieve the desired state in the working copy (this is often more
easily said than done!).
But I don't think subversion should enforce one particular merge outcome.
My opinion is that the user should be given a choice, and be supported
by an interactive conflict resolution prompt that shows all possible
resolution strategies:
- put all files in the same directory ("Markus Schaber's strategy")
- rename the local directory
- rename the incoming directory
- delete the local directory, replace with incoming directory
- discard the incoming directory, keep the local directory
- discard both directories
- etc... (are there any more possibilities?)
This is what I hope Subversion will eventually be able to do.
There's a ton of work left until we get there and it's not an
easy problem to solve.
However, the foundations that 1.7 provides with wc-ng are already
bearing fruit, and make progress a lot easier than it was with 1.6.
We started working on better support for local moves on trunk after
1.7 was branched about a month ago. Right now I have svn status
showing me tree conflicts such as:
$ svn status
R + C xx
> moved from alpha
> local moved here, incoming add upon update
D C alpha
> moved to xx
> local moved away, incoming edit upon update
Summary of conflicts:
Tree conflicts: 2
$
This would have been impossible to implement within a similar time
frame in the Subversion 1.6 code base.
I don't know yet how far we will get for 1.8. We probably won't be
showing the interactive prompt I described above. But there is still
a lot of time left until 1.8.0 and we'll try to make as much progress
as possible.
If you have any more suggestions or ideas, please keep sharing them.
Now is an excellent time for this. Thanks.
AW: Tree Conflicts with Subversion 1.7
Posted by Markus Schaber <m....@3s-software.com>.
Hi,
Von: Stefan Sperling [mailto:stsp@elego.de]
> On Thu, Aug 18, 2011 at 04:54:15PM +0200, Markus Schaber wrote:
> > Hi,
> >
> > Can Subversion 1.7 still have tree conflicts?
>
> Yes. Nothing much has changed on that front for 1.7.
> Foundations for some bigger changes in tree-conflict behaviour planned
for
> 1.8 and later are already being worked on.
>
> > Or can the new working copy break them down to individual conflicts
on
> > files (and directory properties)?
>
> Not sure what you mean here. Can you provide an example?
My idea was that directories itsself would never conflict. If there's a
directory removed, and a new one created with the same name, it is the
same directory, so no tree conflict. If the directories have different
properties, then those properties conflict, and if they have conflicting
files, then those files conflict individually. But no tree conflict.
But maybe my thought is a little bit to short.
Best regards
Markus Schaber
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 |
Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Tree Conflicts with Subversion 1.7
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Aug 18, 2011 at 04:54:15PM +0200, Markus Schaber wrote:
> Hi,
>
> Can Subversion 1.7 still have tree conflicts?
Yes. Nothing much has changed on that front for 1.7.
Foundations for some bigger changes in tree-conflict behaviour planned
for 1.8 and later are already being worked on.
> Or can the new working copy break them down to individual conflicts on
> files (and directory properties)?
Not sure what you mean here. Can you provide an example?