1

After moving our SVN server to a completely different machine, at a different path, I just found out that all of our development team cannot merge correctly anymore.

Specifically, the problem is somewhat similar to that of this question, however this does not seem to be a path case sensitivity issue.

More into details, here is what we are currently using:

  • Subversion: 1.8.16 (32 bit)
  • ToitoiseSVN: 1.9.4 (64 bit)
  • Server: moved from Ubuntu 12 (32 bit) to Windows 10 (64 bit)

As I said, this issue is similar to the one in the linked question, however in this case I have checked the repository path in the local working copy and the path from which the merge is done, and they are identical.

I have also tried doing a fresh checkout, but still no luck: TortoiseSVN says that the working copy properties were updated, but really weren't.

After merge, TortoiseSVN says that the working copy properties were updated

When committing the merge, in fact, I do not see the property update.

Here the properties on the working copy are missing

If I add them manually, then all goes well.

Properties manually updated

What can I do to solve this problem, short of manually recording mergeinfo each and every time?

Community
  • 1
  • 1
Matteo Tassinari
  • 18,121
  • 8
  • 60
  • 81

2 Answers2

0

in the first image it see you are merging from 20.0.1.45 to your local copy.. I think you should reverse source and target of your merging



update after clearing in the comments...

I would do all branching/merging operations directely on server and then work on a local copy of the branched version with normal command chekout and commit.

In this way, if several programmers are working on the same branch, then they can share their changes and work with classical update,checkout and commit operations.

So, in your case, if your local project point to the trunk I simply update/checkout from trunk to local, otherwise merge on the svn server project which you are pointing to, commit the merge, and then update in your local copy.

Ciro Corvino
  • 2,038
  • 5
  • 20
  • 33
  • Why would I need to do so? I need to bring the latest commits from the trunk, which is on our SVN server, to my local working copy, so I think it is correct merging from http://server/trunk -> C:/.../working_copy – Matteo Tassinari Jun 23 '16 at 08:40
  • I would also add, if the "flux" of data is wrong, we've always done it wrong up to now... but at least mergeinfo did get saved before! – Matteo Tassinari Jun 23 '16 at 08:41
  • Ok, it seemed to me that you have wanted to merge your local changes to trunk.. However, I find a bit strange do merging directly from the trunk on a local copy.. I would do all branching/merging operations directely on server and then work on a local copy of the branched version with normal command chekout and commit.. – Ciro Corvino Jun 23 '16 at 09:07
  • so, in your case, if your local project point to the trunk I simply update/checkout from trunk to local, otherwise merge on the svn server project which you are pointing to, commit the merge, and then update in your local copy.. – Ciro Corvino Jun 23 '16 at 09:07
  • I understand now... however, that doesn't seem the usual way to do this kind of operation, see for example http://stackoverflow.com/questions/399669/merge-trunk-to-branch-in-subversion or http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html, it seems always to go from server to local working copy... I'll try that anyway! – Matteo Tassinari Jun 23 '16 at 10:01
  • well, in this way, it is as if you were working without a branch on server but directly on your local machine, and each programmer works on a personal branch directly on his local machine.. but if several programmers are working on the same branch, then it is better have that branch on sever and work with calssical update/checkout and commit operations (to be continued... ) – Ciro Corvino Jun 23 '16 at 11:50
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/115404/discussion-between-matteo-tassinari-and-ciro-corvino). – Matteo Tassinari Jun 23 '16 at 11:51
  • ...at the end of the all changes required you integrate the branch on the trunk. Then you may also delete the branch not more in working. If you think that the solution I gave you it is right I appreciate if you may confirm. I move the comment with the suggested soluton in a section labeled as "update" in the upon answer. Thank you – Ciro Corvino Jun 23 '16 at 11:52
  • Moved to chat: http://chat.stackoverflow.com/rooms/115404/discussion-between-matteo-tassinari-and-ciro-corvino – Matteo Tassinari Jun 23 '16 at 11:56
0

I'd want to thank @CiroCorvino for his help, both though comments and chat, but in the end I found the issue.

The problem seems due to the fact that we not only moved the server, but also went from subversion 1.6 to 1.8

Running the command svnadmin upgrade /path/to/repository seems to have solved the problem, and now the subversion mergeinfo is saved correctly and automatically.

Matteo Tassinari
  • 18,121
  • 8
  • 60
  • 81