[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Lost work due to non-cummutative merges

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 23 Jun 2011 03:03:05 +0300

I also expected step 4 to conflict, and I also don't get a conflict:

[[[
9,% ./new.sh
### Making a Greek Tree for import...
### Done.

### Importing it...

Committed revision 1.
### Done.

9,% cd wc1/trunk/
9,% $svn cp -q A A2
9,% $svn ci -q -m branch
9,% :>A/mu
9,% $svn ci -q -mrm A
9,% $svn up -q
9,% cp A2/mu A/mu
9,% $svn ci -q -madd A
9,% $svn up
Updating '.':
At revision 4.
9,% $svn merge -c 4 A A2
--- Recording mergeinfo for merge of r4 into 'A2':
 U A2
9,% $svn ci -mmerge
Sending A2

Committed revision 5.
9,% cat A2/mu
This is the file 'A/mu'.
9,%
]]]

Maybe Johan can explain that :)

Christoph Bartoschek wrote on Wed, Jun 22, 2011 at 21:25:29 +0200:
> Hi,
>
> we have the following situation:
>
> 1. A branch is created from trunk.
> 2. In trunk a line of code is added and commited as revision X
> 3. The line is removed again and commited as revision X+1
> 4. In branch changeset X+1 is merged from trunk
> 5. In branch changeset X is merged from trunk.
>
> The problem is now that in the branch the line is still there and
> one gets no warning from subversion that something is wrong.
>
> Is this a bug in subversion? Why isn't there at least a merge
> conflict for step 4?
>
> Christoph
Received on 2011-06-23 02:03:48 CEST

This is an archived mail posted to the Subversion Users mailing list.