Maintain git and CVS synchronized - Revision history

Jerico.dev: HOW-TO use git and CVS in parallel moved to Maintain git and CVS synchronized

2010-02-09T15:46:57Z

HOW-TO use git and CVS in parallel moved to Maintain git and CVS synchronized

Jerico.dev: Adding -f switch

2010-02-09T04:01:52Z

Adding -f switch

Jerico.dev: Merging the two commands

2010-02-09T03:50:31Z

Merging the two commands

Jerico.dev: Added path to Eclipse keyword expansion configuration pane

2009-11-18T04:48:53Z

Added path to Eclipse keyword expansion configuration pane

Jerico.dev: Use -kk to avoid differences between CVS and git

2009-11-18T04:46:11Z

Use -kk to avoid differences between CVS and git

Jerico.dev: Make sure that emacs users don't feel bad.

2009-11-18T00:23:23Z

Make sure that emacs users don't feel bad.

Jerico.dev: minor clarifications

2009-11-18T00:19:36Z

minor clarifications

Jerico.dev: minor improvement

2009-11-18T00:17:23Z

minor improvement

Jerico.dev: clarification

2009-11-18T00:14:52Z

clarification

Jerico.dev: Small clarification

2009-11-18T00:13:43Z

Small clarification

@@ Line 51: / Line 51: @@
 I assume that you don't have personal branches in your remote repository yet. But if you have you can check out any other remote branch of course. It doesn't have to be 'origin/master':
-  git checkout -b master origin/master
+  git checkout -f -b master origin/master
 = Creating and updating the pkp-lib submodule =

@@ Line 51: / Line 51: @@
 I assume that you don't have personal branches in your remote repository yet. But if you have you can check out any other remote branch of course. It doesn't have to be 'origin/master':
- git checkout origin/master
+  git checkout -b master origin/master
   git checkout -b master
 = Creating and updating the pkp-lib submodule =

@@ Line 16: / Line 16: @@
 * I assume that you already have a PKP-application (say OMP) checked out from CVS in a folder. I'll reference to this directory by '/omp'. Replace 'omp' with the application you want to check out wherever it occurs.
-* git knows nothing about keyword expansion. Please make sure that you update your whole source tree from CVS with the -kk option to avoid differences between git and CVS checkouts. The -kk option is sticky so this has only to be done once for every source tree.
+* git knows nothing about keyword expansion. Please make sure that you update your whole source tree from CVS with the -kk option to avoid differences between git and CVS checkouts. The -kk option is sticky so this has only to be done once for every source tree. Eclipse allows you to set the -kk option in the 'Window->Preferences->Team->CVS->Files and Folders'.
 * I also assume that you've checked out the pkp library in the folder 'lib/pkp' and that you have it under CVS version control.
 * You should have read the [[git sub-module tutorial]]. I assume that you've understood git and git submodule basics.

@@ Line 16: / Line 16: @@
 * I assume that you already have a PKP-application (say OMP) checked out from CVS in a folder. I'll reference to this directory by '/omp'. Replace 'omp' with the application you want to check out wherever it occurs.
 * I also assume that you've checked out the pkp library in the folder 'lib/pkp' and that you have it under CVS version control.
 * You should have read the [[git sub-module tutorial]]. I assume that you've understood git and git submodule basics.

@@ Line 20: / Line 20: @@
 * You should have forked the official PKP repositories on github as described in [[HOW-TO check out PKP applications from git]]. Just do the remote forking, do nothing locally. What we describe here is an alternative approach.
 * Please replace 'youruser' with your github user wherever it occurs.
 = Initialize the git repository =

@@ Line 11: / Line 11: @@
 This way we get the best out of both worlds:
 * We get full git flexibility at development time removing the overhead of sending around large patch sets and allowing granular control and transparency of development advances throughout the team even when it takes weeks or months until a stable change-set is ready for publication on CVS.
-* CVS OTOH will remain there as a well-known, well-established source repository, accessible to less tech-savvy outside users that only want to track stable changes.
+* CVS OTOH will remain there as a well-known, well-established, tool-rich source repository, accessible to less tech-savvy outside users that only want to track stable changes.
 = Prerequisites and Assumptions =

@@ Line 3: / Line 3: @@
 The idea of using .git and CVS in parallel is that both version control systems use files in sub-directories to keep track of versioning state. And both have a mechanism to ignore directories that should not be tracked. So we simply use both tools in the same folder letting each of them ignore the other.
-We also benefit from the fact that git doesn't mind where a certain file comes from historically (i.e. checked out from CVS or from git). As long as it has the correct SHA1 hash git will recognize it as "equal" to the objects in its object database. This makes it possible to make a change, check it into CVS, wait until the change gets pushed into the git repository, fetch it from there and not get a merge conflict when the file comes in through this channel. As soon as git receives a change sent out by CVS the updated files will simply no longer be marked 'changed' in the workspace.
+We also benefit from the fact that git doesn't mind where a certain file comes from historically (i.e. checked out from CVS or from git). As long as it has the correct SHA1 hash git will recognize it as "equal" to the objects in its object database. This makes it possible to make a change, check it into CVS, wait until the change gets pushed into the git repository, fetch it from there and not get a merge conflict when the file comes in through the back door into git. As soon as git receives a change sent out by CVS the updated files will simply no longer be marked 'changed' in the workspace.
 That way we can use git for development and communication between developers and for local day-to-day version control. Developers can also maintain several development topics they work on in parallel in distinct branches and switch from one to the other whenever they like. In short: all the nice things that git enables.