On Mon, 22 Aug 2011 14:36:36 +, 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
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 ge
On Mon, Aug 22, 2011 at 01:49:45PM +0200, Andreas Krey wrote:
> On Mon, 22 Aug 2011 12:38:40 +, 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 me
On Mon, 22 Aug 2011 12:49:25 +, 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
On Mon, 22 Aug 2011 12:38:40 +, 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 i
On Fri, Aug 19, 2011 at 12:20:56PM +0200, Andreas Krey wrote:
> On Thu, 18 Aug 2011 20:46:51 +, 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 mer
On Fri, Aug 19, 2011 at 04:15:38PM +0200, Andreas Krey wrote:
> On Fri, 19 Aug 2011 13:51:40 +, 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 indepe
On Fri, 19 Aug 2011 13:51:40 +, 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 ju
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 asy
On Thu, 18 Aug 2011 20:46:51 +, 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 inv
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 o
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 int
On Thu, Aug 18, 2011 at 07:22:28PM +0200, Andreas Krey wrote:
> On Thu, 18 Aug 2011 18:13:09 +, 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 interac
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 origi
On Thu, 18 Aug 2011 18:13:09 +, 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 str
Markus Schaber wrote on Thu, Aug 18, 2011 at 17:30:59 +0200:
> Hi,
>
>
> Von: Stefan Sperling [mailto:s...@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 th
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, t
Hi,
Von: Stefan Sperling [mailto:s...@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 behaviou
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
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 | Develope
20 matches
Mail list logo
