2

I'm using svnsync to migrate a (large) repository to a new server. I started running it last night. It got about 1/3 of the way through before a network timeout interrupted it. I resumed the sync this morning, so it'll now run during the day.

Since people still need to work, is there any problem if people continue to commit to the SOURCE repository while the synchronize operation is running?

Kricket
  • 4,049
  • 8
  • 33
  • 46
  • I can't find proofs, but I believe people **can** commit safely – Sergey Azarkevich Jun 04 '15 at 07:46
  • I get the same impression, but I was hoping somebody had an actual reference (or experience). – Kricket Jun 04 '15 at 07:55
  • I had such expirience. We setup jenkins to run svnsync after each commit and there was no problems. – Sergey Azarkevich Jun 04 '15 at 07:58
  • That's not quite the same thing. svnsync will just synchronize the un-synchronized revisions, so your jenkins job essentially just grabbed the latest commit and made a backup. My problem is more that I have a long synchronize job, and I need to know if people can commit to the source WHILE synchronize is still running. – Kricket Jun 04 '15 at 08:11
  • I don't think it is really different. First svnsync transfer 1:HEAD, subsequent calls transfer N:HEAD. As I understand svnsync uses same protocol for retrieve changes as command ine tools, so it can't grab incorrect/incomplete commit at all. – Sergey Azarkevich Jun 04 '15 at 08:23
  • So you're saying each revision sync is an atomic operation? In other words, the synchronize operation is actually a whole bunch of smaller operations run successively? (I suspect you're right, but can you find a reference?) – Kricket Jun 04 '15 at 08:51
  • Yes I think. But, sadly, I can't find references... – Sergey Azarkevich Jun 04 '15 at 09:09
  • This guy recommends NOT changing the source: http://www.cmsproducer.com/analysis/infrastructure/svn-subversion-sync-remote-server-repository – Kricket Jun 04 '15 at 12:49
  • BTW, svn book say: "Rather than initialize a brand new repository as a mirror and then syncronize all of the history into it, administrators will find it significantly faster to first make a copy of the mature repository (perhaps using svnadmin hotcopy) and then use svnsync initialize --allow-non-empty to initialize that copy as a mirror which is now already up-to-date with the original.". This can solve problem with long first sync. – Sergey Azarkevich Jun 04 '15 at 12:56
  • The problem with that is, I don't have filesystem access to either of the repos, so I can't use svnadmin. (Although I did consider using svnrdump, but decided svnsync boiled down to the same thing, without having to make a big dump file.) – Kricket Jun 04 '15 at 13:21

1 Answers1

1

No, it doesn't.

I really dug around all over the interwebs, but couldn't find any reference. We decided to take the risk and try it. The commit went through and svnsync continued to run without any apparent problems.

HOWEVER: the sync will stop before it gets to the latest revision. For example: suppose, when you start synchronizing, the last revision is 100. During the synchronize operation, you commit r101. In this case, svnsync will stop at revision 100. Thus, you need to re-run svnsync to get the last remaining revision.

Kricket
  • 4,049
  • 8
  • 33
  • 46