Difference between revisions of "CVS2SVN"

Jump to navigation Jump to search
32 bytes added ,  09:47, 7 September 2007
Fix typos as people seem to use this document.
m (improved spelling)
(Fix typos as people seem to use this document.)
 
Line 31: Line 31:
== The process ==
== The process ==


To successfully fullfill the task I wrote several simple scripts. I had to do it in scripts, not manually, because restoration of connections is pretty long process, and I wanted to minimize the repository freeze time. So I first modified the dump file locally, and later reapplied my changes to the fresh dump. Those scripts are intentionally kept simple and no error checking is performed.
To successfully fullfill the task I wrote several simple scripts. I had to do it in scripts, not manually, because restoration of connections is pretty long process, and I wanted to minimize the repository freeze time. So first I modified the dump file locally, and later reapplied my changes to the fresh dump. Those scripts are intentionally kept simple and no error checking is performed.


The whole dump takes over 1.4GB, so there is no way to edit the file directly. Hence I came up with the simple idea of extracting just those Revision numbers and Node-paths, so they could be later replaced in the original dump.
The whole dump takes over 1.4GB, so there is no way to edit the file directly. Hence I came up with a simple idea of extracting just those Revision numbers and Node-paths, so they could be later replaced in the original dump.


=== automation-pass1.pl ===
=== automation-pass1.sh ===


   wget http://.../scummvm-cvsroot.tar.bz2
   wget http://.../scummvm-cvsroot.tar.bz2
Line 68: Line 68:
=== Manual editing ===
=== Manual editing ===


Now I opened the dump.nodes.in files in XEmacs and started to add those links. First, I searched it for the word 'delete' and studied each case. I had to consult files layout and CVS log messages to see either those files were simply killed or really moved or renamed. Due to the fact that some files were really renamed, and there are name clashes between files in directories, it was not possible to fully automate the task, however a big chunk of it could be scripted.
Now I opened the dump.nodes.in files in XEmacs and started to add those links. First, I searched it for the word 'delete' and studied each case. I had to consult files layout and CVS log messages to see if those files were simply killed or really moved or renamed. Due to fact that some files were really renamed, and there are name clashes between files in directories, it was not possible to fully automate the task, although big chunk of it could be scripted.


So what I did is to specify that Node-copyfrom-path: manually and left Node-copyfrom-rev blank. Then I recorded a simple macro in XEmacs, as that was quicker to do than writing yet another script. The macro was something like this:
So what I did is specified that Node-copyfrom-path: manually and left Node-copyfrom-rev blank. Then I recorded a simple macro in XEmacs, as that was quicker to do than writing yet another script. The macro was something like this:


* It starts on Node-copyfrom-path line.
* It starts on Node-copyfrom-path line.
* Put path in yank buffer
* Put path to yank buffer
* Kill other windows
* Kill other windows
* Split window (thus we have 2 views of buffer at the same place)
* Split window (thus we have 2 views of buffer at the same place)
* Switch to another window
* Switch to another window
* Search backwards contents of yank buffer
* Search backwards contents of the yank buffer


With this I saw the revision number in another window. I doublechecked that this is the correct place and put that revision number to Node-copyfrom-rev field. However I didn't see any inconsistencies here, so I guess it could insert those numbers fully automatic.
With this I saw the revision number in another window. I doublechecked that this is the correct place and put that revision number to Node-copyfrom-rev field. However I didn't see any inconsistencies here, so I guess it could insert those numbers fully automatic.


Resulting .nodes file has inserted lines marked with leading + like on example at the top of this page.
Resulting .nodes file had inserted lines marked with leading + like on example at the top of this document.


=== automation-pass2.pl ===
=== automation-pass2.sh ===


This one is simple. What it does is merging back those inserted lines and modifying all internal paths, so it will put all modules into separate directories on the SVN repository:
This one is simple. It merges back those inserted lines and modifies all internal paths, so it will put all modules into separate directories of the SVN repository:


   perl merge-dump.pl scummvm.dump.nodes scummvm <scummvm.dump >scummvm.dump.new
   perl merge-dump.pl scummvm.dump.nodes scummvm <scummvm.dump >scummvm.dump.new
Line 136: Line 136:
   }
   }


The second regexp here is tricky, since Node-copyfrom-path could contain either /trunk/scummvm/blah or trunk/scummvm/blah and we have to keep that leading slash of it present.
The second regexp here is tricky, since Node-copyfrom-path could contain either /trunk/scummvm/blah or trunk/scummvm/blah and we have to keep that leading slash if it is present.


So after this stage the amount of data on disk doubles since we have both merged and non-merged dumps. I kept non-merged dumps, so pass2 could be redone without performing lengthy pass1 over again.
So after this stage the amount of data on the disk doubles since we have both merged and non-merged dumps. I kept non-merged dumps intact, so pass2 could be redone without performing lengthy pass1 over again.


=== automation-pass3.sh ===
=== automation-pass3.sh ===
Line 215: Line 215:
== Final step ==
== Final step ==


Then the repository was dumped, bzipped and uploaded to sf.net. Now it is possible to import the existing dump, but at the time we did it, we had to submit a PR.
Last step is dump the repository, bzip it and upload to sf.net. Later SF.net added possibility to import an existing dump automagically, but at the time we performed the move, we had to submit a PR.

Navigation menu