On Fri, Oct 3, 2008 at 12:15 PM, Ryan Schmidt <
subversion-2008c_at_ryandesign.com> wrote:
> On Oct 2, 2008, at 6:56 PM, Babak S. H. wrote:
>
> before setting up a bug report in the svn bug database,
>> we wanted to query this mailing list in the hope of getting an explanation
>> for the following strange behaviour in a merge scenario:
>>
>> 1) A virgin repository is created (https://chucky:8443/svn/rep1)
>> containing
>> the directories "branches", "tags" and "trunk".
>>
>> 2) Repository is checked out in a working copy:
>> svn co https://chucky:8443/svn/rep1 wc
>>
>> A wc\trunk
>> A wc\branches
>> A wc\tags
>> Checked out revision 1.
>>
>> 3) Code project folder "proj" is copied into trunk. Folder "proj"
>> contains merely the file test.cpp.
>>
>> 4) "proj" is added to be version managed via svn:
>> svn add wc/trunk/proj
>>
>> A wc\trunk\proj
>> A wc\trunk\proj\test.cpp
>> -------------------------------------
>> svn commit wc/trunk/proj -m "Genesis"
>>
>> Adding wc\trunk\proj
>> Adding wc\trunk\proj\test.cpp
>> Transmitting file data .
>> Committed revision 2.
>>
>> 5) A private feature branch is created from trunk into branches:
>> svn copy https://chucky:8443/svn/rep1/trunk/proj https://chucky
>> :8443/svn/rep1/branches
>>
>> Committed revision 3.
>>
>> 6) Working copy is sync'ed with repository:
>> svn update wc
>>
>> 7) Now we rename in [wc/trunk/proj] test.cpp to xyz.cpp (off course via
>> svn)
>> svn mv test.cpp xyz.cpp
>> A xyz.cpp
>> D test.cpp
>>
>> svn commit -m "Moved test.cpp to xyz.cpp"
>> Deleting proj\test.cpp
>> Adding proj\xyz.cpp
>>
>> Committed revision 4.
>>
>> 8) Directory is changed to [wc/branches].
>> We want to merge the recent changes in the baseline aka trunk
>> (literally the diff between revisions 2 up to 4) into our private
>> feature branch:
>> svn merge -r 2:4 https://chucky:8443/svn/rep1/trunk/proj proj
>>
>> --- Merging r3 through r4 into 'proj':
>> A proj\xyz.cpp
>> D proj\test.cpp
>>
>> 9) In [wc/branches/proj] we modify the content of xyz.cpp and commit it
>> creating svn revision 6.
>>
>>
>> 10) Now we want to merge back the work in our branch into the
>> baseline(trunk).
>> Directory is changed to [wc/trunk].
>>
>> svn merge --dry-run -r 3:6 https://chucky:8443/svn/rep1/branches/proj
>> proj
>>
>> --- Merging r4 through r6 into 'proj\xyz.cpp':
>> C proj\xyz.cpp
>> Skipped missing target: 'proj\test.cpp'
>>
>>
>> We wonder about the skipped missing target (proj\test.cpp) message which
>> actually shouldn't be any longer around neither in the private feature
>> branch
>> nor in trunk after the first merge and commit (steps: 8+9).
>>
>> Any hints ?
>>
>
>
> Wrong merge.
>
> You already merged changes from trunk into the branch. To now bring the
> changes from the branch into the trunk, you should therefore do this merge:
>
> svn merge https://chucky:8443/svn/rep1/branches/proj@6 https://chucky
> :8443/svn/rep1/trunk/proj_at_6 proj
>
>
> If you are not yet upgraded to at least Subversion 1.5 on both the client
> and the server, you may want to do so. Then you can use the new merge
> tracking features and don't have to worry about specifying revisions to
> merge. Read about them here:
>
> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html
>
>
Hello Ryan,
I off course know that I have merged changes from trunk into the branch.
You say "wrong merge" without proving your statement. What's wrong with it?
I want my NEW work in the branch (containing the complete work from the
baseline after merge)
to be available in the trunk again.
It is then logically to build up the difference between the revision where I
created
my branch (rev.3) up to the branch's head revision (rev.6) and apply that
diff on the
head of the baseline=trunk in a checked out working copy.
I think it is nonsense that svn even mentions "proj/test.cpp", since that
file was deleted from both the repository and my working copy.
I read subversion has an issue during "merges and moves" as mentioned in
the svn documentation.
*Citation form [http://svnbook.red-bean.com/en/1.5/svn-book.html]:*
"*Merges and Moves
A common desire is to refactor source code, especially in Java-based
software projects.
Files and directories are shuffled around and renamed, often causing great
disruption to everyone working on the project. Sounds like a perfect case to
use a branch, doesn't it? Just create a branch, shuffle things around, and
then
merge the branch back to the trunk, right?
Alas, this scenario doesn't work so well right now and is considered one
of Subversion's current weak spots. The problem is that Subversion's svn
update
command isn't as robust as it should be, particularly when dealing with copy
and move operations.
When you use svn copy to duplicate a file, the repository remembers where
the new
file came from, but it fails to transmit that information to the client
which is
running svn update or svn merge. Instead of telling the client, "Copy that
file
you already have to this new location," it sends down an entirely new file.
This can lead to problems, especially because the same thing happens with
renamed files.
A lesser-known fact about Subversion is that it lacks "true renames"—the svn
move
command is nothing more than an aggregation of svn copy and svn delete.*"
---------------------------------------------------------------------------------------------------------
You suggest to do the following merge instead:
svn merge https://chucky:8443/svn/rep1/branches/proj@6
https://chucky:8443/svn/rep1/trunk/proj@6 proj
which builds the difference $DELTA from $A=[branches/proj_at_6] to
$B=[trunk/proj_at_6]
and applies it on a local working copy of proj in the trunk directory.
Note that $DELTA is a diff that transforms $A into $B when applied on a
working copy of $B.
In our case, I think it is wrong to do this merge, since it looses
information.
$A has work ($W) that is new and hence not available inside $B yet.
$DELTA would remove $W from $B when it were available there.
Since it is not, nothing is deleted in $B, but,
at the same time we fail to transfer our new work $W into $B. That's how
information is lost.
The vice versa merge into "proj" directory inside trunk works, though:
svn merge https://chucky:8443/svn/rep1/trunk/proj@HEAD
https://chucky:8443/svn/rep1/branches/proj@HEAD proj
I am not sure, whether this merge is logically equivalent to my back merge
described in
step 10 of my first mail:
##################################################################################
10) Now we want to merge back the work in our branch into the
baseline(trunk).
Directory is changed to [wc/trunk].
svn merge --dry-run -r 3:6 https://chucky:8443/svn/rep1/branches/projproj
--- Merging r4 through r6 into 'proj\xyz.cpp':
C proj\xyz.cpp
Skipped missing target: 'proj\test.cpp'
##################################################################################
--
Regards.
Babak Sayyid Hosseini
Received on 2008-10-04 01:06:53 CEST