Am 16.10.2012 18:02, schrieb Stefan Sperling:
> On Tue, Oct 16, 2012 at 01:17:40PM +0200, Sven Uhlig wrote:
>> Below is a .bat file for creating the repo with some more conflicts that
>> we do not understand. I would be happy if someone could explain these as
>> well.
>
> Please see my remarks below.
Thank you to all your response! I didn't expect to get a in-depth answer
this quickly - though I am very happy to see this rate of activity :)
>> echo .>first.txt
>> svn add first.txt
>> svn commit -m "1st"
>>
>> svn copy -m "prj0" . "^/branches/prj0"
>
> You're copying a mixed-revision working copy here.
> Is that really what you want?
> ^/branches/prj0 is a copy of ^/trunk_at_1
> ^/branches/prj0/first.txt is a copy of ^/trunk/first.txt_at_2.
> See http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs
You are right. That is not what I want. This was just a test to see if
this will cause errors.
Usually we use TortoiseSVN to do everything with SVN and it seems this
is what happens behind the scenes of TSVN. I know this is the wrong list
to discuss this topic.
I will remove this from any further replies from me.
>> svn switch "^/branches/prj2"
>> svn merge "^/branches/prj1"
>
> prj1 is a branch off trunk, and so is prj2.
> Which means prj1 and prj2 are not ancestrally related.
But they have the same ancestry, at least the same directory, may be not
the same revision. This is ok for my understanding.
> Ideally, you'd reintegrate prj1 into trunk first and then merge the
> changes into prj2 from trunk, using a sequence such as:
I guess this merge was a bad example and wrong as well. There could be
changes that are commited to prj1 that are requried in prj2 because of
e.g. some shared code.
I would do this with the following command:
svn merge -r A:B "^/branches/prj1"
Reintegration is not an option because the development will continue on
both branches in parallel.
>> svn switch "^/branches/prj1"
>> svn merge "^/trunk"
>> svn commit -m "prj1 sync"
>
> What is the purpose of this sync merge?
This is to sync the branch with the changes from trunk. For me it looks
like how it is done in the SVN book.
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.stayinsync
>> svn switch "^/branches/testing"
>> svn merge "^/branches/prj1"
>> svn commit -m "prj1 into testing"
>>
>> svn merge "^/branches/prj2"
>
> Again, you hit a similar problem here.
I do not understand why there is a conflict in "second.txt".
As far as I can see it the following files are the same:
- /branch/prj1/second.txt
- /branch/prj2/second.txt
/branch/prj1/second.txt was added and never changed
> svn switch "^/branches/prj1"
> svn add second.txt
> svn commit -m "2nd"
/branch/prj2/second.txt was also added and never changed
> svn switch "^/branches/prj2"
> svn merge "^/branches/prj1"
> svn commit -m "prj1 into prj2"
With svn:mergeinfo the SVN should have enough information to see that
the files are the same. There was no change and the original source is
the same (/branches/prj1/)
> What is the purpose of the separate 'testing' branch? Why are you not
> testing prj1 directly, reintegrate it into trunk when tests succeed,
> and then sync all your other branches to trunk to merge prj1 changes
> into them?
The tests are made in the branches directly at first. After that the
changes are merged to the testing branch to check how it looks like with
all the other changes in development.
The whole project is for a website. Because there are so many small
changes that do not need a real independet branch, there is a generic
development branch "testing" and there are no version tags.
When the small changes are OK, they are merged to trunk which represents
the live server. (instead of tags)
Changes that are not OK, may get reverted or updated later.
> If you did that, your approach of using 'svn merge ^/some-branch'
> would work fine. But make sure to use the --reintegrate option whenever
> you merge one of your branches back into trunk (fortunately, the requirement
> to use --reintegrate will go away in Subversion 1.8, but for now you must
> still use it).
See above:
Reintegration is not an option because the development will continue on
both branches in parallel.
> See the output of 'svn help merge' for more details. It has some diagrams
> to illustrate which 'svn merge' invocation is appropriate for a given
> merge scenario.
It seems there is no such scenario documented until now ;)
> If you really must merge between unrelated branches, use the 2-URL
> merge syntax
This seems to be the only solution - before looking at your third e-mail
from today, 10:00 GMT.
So the only open question in this mail is the conflict regarding
second.txt and the merge into /branches/testing/.
Best regards
Sven.
Received on 2012-10-17 17:31:30 CEST