Question

We had this small development project which hadn’t been managed using version control system.
Two people were working on the original code-base,so that there were two slightly different copies of the original code-base.
Say these copies “copyA” and “copyB”.

Now I tried to create a SVN repository for these two copies.
I put “copyA” in the trunk and “copyB” in a branch called “branchB”.

Afterwards two developers started working on these two repository paths. (“trunk” and “branchB”).

Then we needed to merge these two branches ,but seems it didnt produce correct result.

Is it necessary that the branches were diverged from the same “code-base” in order to merge in a later stage ?

In my case there wasn’t a single “code-base”. Two of the “copyA” and “copyB” were committed to SVN separately .

Answer 1

It is best if the two branches have the same starting point.
You can "merge" two unrelated branches in SVN (section "Merges Without Mergeinfo"):

Merging unrelated sources

If you ask svn merge to compare two URLs that aren’t related to each other, a patch will still be generated and applied to your working copy, but no merging metadata will be created. There’s no common history between the two sources, and future “smart” merges depend on that common history.

Note that this a situation where git would be more efficient, since it easy to setup two branches, each starting with "copyA", and erase the content of the second branch with "copyB" (git would detect all the renames, moves and additions introduced by "copyB" compared to "copyA").
If if you had created two unrelated branches in git, you would still be able to fake a common history and merge them.