Projects/MoveToGit/UsingSvn2Git - Revision history

Nicolás: /* Servers to use for all developers */ we have only one server now

2012-09-14T17:38:54Z

‎Servers to use for all developers: we have only one server now

Sdoerner: Add "post-processing" section explaining parent maps and the fix-tags script.

2012-08-05T13:45:27Z

Add "post-processing" section explaining parent maps and the fix-tags script.

AnneW at 15:38, 19 July 2012

2012-07-19T15:38:09Z

Wrohdewald: renamed kde_svn to svn because svn is hardcoded in kde-ruleset/bin/startSync

2012-03-16T07:07:31Z

renamed kde_svn to svn because svn is hardcoded in kde-ruleset/bin/startSync

Santa: /* Getting the tools */

2011-07-02T00:01:05Z

‎Getting the tools

Neverendingo: Text replace - "" to ""

2011-06-29T20:57:35Z

Text replace - "</code>" to "</syntaxhighlight>"

Neverendingo: Text replace - "`" to ""`


2011-06-29T20:42:21Z
Text replace - "<code bash>" to "<syntaxhighlight lang="bash">"

				
				
				
				
			
			← Older revision
			Revision as of 20:42, 29 June 2011
			
Line 13:
Line 13:
  The necessary tools are hosted at [http://www.gitorious.org/svn2git http://www.gitorious.org/svn2git] and [https://projects.kde.org/projects/playground/sdk/kde-ruleset https://projects.kde.org/projects/playground/sdk/kde-ruleset]. To get started do:   The necessary tools are hosted at [http://www.gitorious.org/svn2git http://www.gitorious.org/svn2git] and [https://projects.kde.org/projects/playground/sdk/kde-ruleset https://projects.kde.org/projects/playground/sdk/kde-ruleset]. To get started do:
    
− <code bash> + <syntaxhighlight lang="bash">
  git clone git://gitorious.org/svn2git/svn2git.git   git clone git://gitorious.org/svn2git/svn2git.git
  git clone git://git.kde.org/kde-ruleset   git clone git://git.kde.org/kde-ruleset
Line 68:
Line 68:
  For more examples see the svn2git/samples/ directory and the rules in the kde-ruleset repository.   For more examples see the svn2git/samples/ directory and the rules in the kde-ruleset repository.
    
− The recurse action is a hack to tell svn2git to recurse into a directory it has just copied or that existed because it is of interest. Example: if we are importing kdelibs, it exists in {{path|trunk/KDE/kdelibs}}. At branching, someone did: <code bash>svn cp $SVNROOT/trunk/KDE $SVNROOT/branches/KDE/4.4</code> + The recurse action is a hack to tell svn2git to recurse into a directory it has just copied or that existed because it is of interest. Example: if we are importing kdelibs, it exists in {{path|trunk/KDE/kdelibs}}. At branching, someone did: <syntaxhighlight lang="bash">svn cp $SVNROOT/trunk/KDE $SVNROOT/branches/KDE/4.4</code>
    
  SVN recorded in that commit that branches/KDE/4.4 was the only path changed.     SVN recorded in that commit that branches/KDE/4.4 was the only path changed.



Michalm at 22:52, 29 November 2010
2010-11-29T22:52:48Z


				
				
				
				
			
			← Older revision
			Revision as of 22:52, 29 November 2010
			
Line 68:
Line 68:
  For more examples see the svn2git/samples/ directory and the rules in the kde-ruleset repository.   For more examples see the svn2git/samples/ directory and the rules in the kde-ruleset repository.
    
− The recurse action is a hack to tell svn2git to recurse into a directory it   + The recurse action is a hack to tell svn2git to recurse into a directory it has just copied or that existed because it is of interest. Example: if we are importing kdelibs, it exists in {{path|trunk/KDE/kdelibs}}. At branching, someone did: <code bash>svn cp $SVNROOT/trunk/KDE $SVNROOT/branches/KDE/4.4</code>
− has just copied or that existed because it is of interest. Example: if we are importing kdelibs, it exists in {{path|trunk/KDE/kdelibs}}. At branching, someone did: <code bash>svn cp $SVNROOT/trunk/KDE $SVNROOT/branches/KDE/4.4</code> + 
    
  SVN recorded in that commit that branches/KDE/4.4 was the only path changed.     SVN recorded in that commit that branches/KDE/4.4 was the only path changed.  



Tnyblom: /* Checking for proper history in the new git repository */
2010-11-04T19:18:10Z
‎Checking for proper history in the new git repository

				
				
				
				
			
			← Older revision
			Revision as of 19:18, 4 November 2010
			
Line 190:
Line 190:
  If you choose to delete them manually please make sure to document this with a textfile or inside the rule file so if someone else does the conversion later again he'll know what manual steps you did.   If you choose to delete them manually please make sure to document this with a textfile or inside the rule file so if someone else does the conversion later again he'll know what manual steps you did.
    
− Before publishing the newly created git repository make sure to repack it. This can greatly reduce it's size (i.e. Phonon's git repository could be shrunken from 18 MB to 5.2 MB) + Also try grepping the output from svn2git for the string '"copy from"' (with the double quotation marks). This will give you a list of revisions/paths that svn2git could not detect the origin of. That is someone did a svn cp/mv and the old path is not in the generated git repository.
    
  + Before publishing the newly created git repository make sure to repack it. This can greatly reduce it's size (i.e. Phonon's git repository could be shrunken from 18 MB to 5.2 MB)
    
  ==== Pushing the Repository to git.kde.org ====   ==== Pushing the Repository to git.kde.org ====



Tnyblom: /* Important Details */
2010-11-04T19:05:59Z
‎Important Details

				
				
				
				
			
			← Older revision
			Revision as of 19:05, 4 November 2010
			
Line 80:
Line 80:
  ==== Important Details ====   ==== Important Details ====
    
− * All matching rules need to end with a '/', else the tool will crash at some point. This is a known bug. The only exception are the rules using the recurse-action. + * All rules matching directories need to end with a '/', else the tool will crash at some point. This is a known bug. The only exception are the rules using the recurse-action.
    
− * Matching rules can use Regular Expressions (according to the QRegExp syntax) in the match line and can use backreferences in the repository and branch parameters using \n (n=1,2,3,...) to reduce the amount of rules. + * All rules matching files need to use the prefix rule.
  +  
  + * Matching rules can use Regular Expressions (according to the QRegExp syntax) in the match line and can use backreferences in the repository, prefix and branch parameters using \n (n=1,2,3,...) to reduce the amount of rules.
    
  * The rules form an ordered list that the tool goes through while matching the changed paths for each commit. So if two rules match the same path and neither of the two has more matching criteria, then the rule that is written further up in the file wins. This is useful to exclude certain commits from the extraction process, if you look at the existing kde ruleset  you'll notice that at the top some revisions are ignored.   * The rules form an ordered list that the tool goes through while matching the changed paths for each commit. So if two rules match the same path and neither of the two has more matching criteria, then the rule that is written further up in the file wins. This is useful to exclude certain commits from the extraction process, if you look at the existing kde ruleset  you'll notice that at the top some revisions are ignored.

@@ Line 4: / Line 4: @@
 === Servers to use for all developers ===
-KDE Sysadmin provides 3 servers which are fully setup for writing rules. You can find more information about that on: http://community.kde.org/Sysadmin/DeveloperAccessForRuleWriting.
+KDE Sysadmin provides a server which is fully setup for writing rules. You can find more information about that on: http://community.kde.org/Sysadmin/DeveloperAccessForRuleWriting.
-All registered KDE developers have access to these machines. The rest of this document assumes a setup on your local computer, you are free to set it up on your local computer, but there is no need to. You can use the servers provided by KDE Sysadmin.
+All registered KDE developers have access to this machine. The rest of this document assumes a setup on your local computer. You are free to set it up on your local computer, but there is no need to. You can use the server provided by KDE Sysadmin.
 === Getting the tools ===

← Older revision		Revision as of 13:45, 5 August 2012
Line 142:		Line 142:

	Once its done you should have a new "module" git repository in your current working directory.		Once its done you should have a new "module" git repository in your current working directory.
		+
		+	==== Post-processing ====
		+	Some problems that might occur in the converted git repository can be fixed after the actual conversion. More specifically, these are wrong parents and empty commit objects for tags.
		+
		+	Wrong parents can be handled using a parent map. This is a file with each line in the format "parent-id child-id", where both ids are the integer numbers of the corresponding svn commit. You can also add newlines and comments starting with #. Each line in the parent map adds an edge in the commit graph from parent to child. This is frequently necessary to correctly reflect merges in the git history. Occasionally, svn2git might add a parent which should not be a parent at all. In this case, you can write a line "clear child-id" to delete that edge, and afterwards add the correct edge as explained above. It is usually easiest to first do a conversion, then look at the result with "gitk --all" and if something is wrong find the svn ids from the git commit message.
		+
		+	To actually perform the fix, run "kde-ruleset/bin/parent-adder $parent_map_file" in the new git repository. You should probably make a backup of the git repository before, as rerunning the conversion would take a lot of time if something goes wrong.
		+
		+	Empty commit objects for tags can be fixed by running "kde-ruleset/bin/fix-tags" in the git repository.
		+
		+	Both processes leave a backup of the original commit objects. These can be removed with "kde-ruleset/bin/remove-fb-backup-refs.sh".

	==== Checking for proper history in the new git repository ====		==== Checking for proper history in the new git repository ====

← Older revision		Revision as of 15:38, 19 July 2012
Line 1:		Line 1:
−	~~{{Template:I18n/Language Navigation Bar\|Projects/MoveToGit/UsingSvn2Git}}~~

	This page documents how to go about getting a KDE module ready for the Great Git Migration of 2010.		This page documents how to go about getting a KDE module ready for the Great Git Migration of 2010.

@@ Line 101: / Line 101: @@
 If there are no rules yet, lets start with the master (aka trunk) branch. The easiest way to find out history with svn is executing:
-<pre>svn log -v --stop-on-copy file:///path/to/kde_svn/trunk/KDE/module</pre>
+<pre>svn log -v --stop-on-copy file:///path/to/svn/trunk/KDE/module</pre>
-Please note that '/path/to/kde_svn/' is the path to the 65GB you downloaded, and the 'trunk/KDE/module' is the module you want to write rules for, but those two put together is *not* a path that physically exists on your disk. svn log is smart enough to do what you want.
+Please note that '/path/to/svn/' is the path to the 65GB you downloaded, and the 'trunk/KDE/module' is the module you want to write rules for, but those two put together is *not* a path that physically exists on your disk. svn log is smart enough to do what you want.
 This will give you a history of the given module in trunk, it'll stop on the first commit that copied the code from somewhere else. The verbose output will allow you to see where this copy came from.
@@ Line 117: / Line 117: @@
 follow this to also get the history imported from the "old" place the module resided. The same svn command can be used with slightly different path argument:
-<pre>svn log -v --stop-on-copy file:///path/to/kde_svn/some/other/path@revision</pre>
+<pre>svn log -v --stop-on-copy file:///path/to/svn/some/other/path@revision</pre>
 The @revision is important as the original path usually doesn't exist anymore. With this we can write the next rule to the rules file and repeat until we've finally reached the point where the code was initially imported into svn (or probably cvs in the old days)
@@ Line 135: / Line 135: @@
 ==== Running svn2git ====
-This is the easiest, but most time-consuming part. As example lets say that in our current working directory we have the kde rules repository in kde-ruleset subdir, the svn2git tool in the svn2git subdir and the KDE repository in the kde_svn subdir:
+This is the easiest, but most time-consuming part. As example lets say that in our current working directory we have the kde rules repository in kde-ruleset subdir, the svn2git tool in the svn2git subdir and the KDE repository in the svn subdir:
 <pre>
-svn2git/svn-all-fast-export --identity-map kde-ruleset/account-map --rules kde-ruleset/module kde_svn
+svn2git/svn-all-fast-export --identity-map kde-ruleset/account-map --rules kde-ruleset/module svn
 </pre>