On Tue, May 12, 2009 at 07:49, victor adan <[email protected]> wrote: > > Hello, > > I just created a new google code project and have a question about > svnsync. > The code I intend to have google host is under Subversion control and > has over 2000 commits. Obviously I don't want to loose all that > precious history. I want to move my entire existing repository from my > privately brewed server to google, and then get rid of my old server > entirely. i.e. I want to effectively replace my old private server > with google code hosting. I found in the FAQ that one should use > svnsync to import an svn repository: > http://code.google.com/support/bin/answer.py?answer=56673&topic=10386 > I'm wondering, though, if this is the correct thing to do for a > complete migration. Reading the svn documentation: > http://svnbook.red-bean.com/en/1.5/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate > It seems that svnadmin dump / load would be the command to use for a > repository migration, but you do not seem to support this. > So my concrete question is this: Is the use of svnsync as you discribe > it in your FAQ *exactly* equivalent to using svnadmin dump / load? If > not, what is the difference? My concern comes from reading a couple of > paragraphs in the svn documentation, section "Repository Replication" > http://svnbook.red-bean.com/en/1.5/svn.reposadmin.maint.html#svn.reposadmin.maint.replication > > "...For this reason, while svnsync cannot demand that the target > repository be read-only, allowing the revision history in the target > repository to change by any mechanism other than the mirroring process > is a recipe for disaster." > > "Do not modify a mirror repository in such a way as to cause its > version history to deviate from that of the repository it mirrors. The > only commits and revision property modifications that ever occur on > that mirror repository should be those performed by the svnsync tool." > > So is svnsync a tool for mirroring only? Or can it be used to perform > an effective migration?
It can be used to perform migration, and it is the only way to perform migration to Google Code. The warning in the Subversion book should be read as: "If you want read-only mirrors, make sure that you never commit anything to it manually, otherwise svnsync will no longer be able to synchronize from the master repository". But, internally, svnsync is a trivial program: it requests a stream of revisions from one server, and replays those revisions in another server. As long as the target server doesn't diverge (ie. doesn't have any commits not in the source), then svnsync can be run incrementally to stay in sync. But you can also just run it once, to sync up two repositories, then throw away the original and start using the synced copy. As for the difference between dump/load and svnsync, the basic difference is that svnsync works entirely through the public server API, whereas dump/load operates directly on repository files. Both mechanisms get you exactly the same data, but implementing only svnsync is much simpler for us. Implementing dump/load would require additional development time and resources for not much benefit. Historically, dump/load was originally easier to have, but over time the need for a public way to do incremental dump/load became obvious, and svnsync came into existence. So, bottom line: yes, use svnsync. If you follow the documentation, consider Google Code to be your "read only mirror". Once the synchronization is complete, just delete (or archive and backup :) your local repository, and start using the Google Code repository as usual. Hope this helps, - Dave > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Hosting at Google Code" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-code-hosting?hl=en -~----------~----~----~----~------~----~------~--~---
