Changes between Version 5 and Version 6 of UsingGitAndSvnInTrac

Timestamp:

05/06/10 22:40:58 (12 years ago)

Author:

cotto

Comment:

make intro less stupid

UsingGitAndSvnInTrac

@@ -1 +1 @@
 (Keeping two revision control systems around is a bad idea. It doubles the maintenance burden, doubles the points of potential failure, and saddles us with maintaining the old system even if we transition to yet a fourth revision control system down the road. If we made the transition, we would have to make it completely, which means figuring out ahead of time how to handle referring to specific revisions, both old and new. --ANR)
 
-So Subversion is old and busted and git is the new hawtness.  This is established and completely beyond question.  Don't question it.  Also, I've wasted way too much time wrestling with svn's stupid quirks and failures, so I want Parrot to switch to using Git as its primary vcs.  The only problem is that Parrot has a lot of links and references to subversion revision numbers, both on this Trac site, in the source, in old messages, lots of places.  We don't want these to break and make people sad.  That means that even after we switch to Git, we'll need to keep the Subversion repository accessible using current links.
+There is a movement within the Parrot development community toward switching to a git as our primary version control system.  Most of the [wiki:GitObjections objections to git] have been addressed and the largest remaining technical problem is backwards compatibility.  Various facets of the Parrot project have direct links and references to subversion revision numbers, e.g. on the Trac site, in the source, in mailing lists and probably elsewhere.  We don't want these to break.  That means that as part of the transition to Git, we'll need to ensure that current links to subversion revisions will continue to lead to a page which displays the correct changeset.
 
-Oh noes!  Trac isn't meant to have multiple version control backends, you might say.  There's a solution:
+A few different options exists to allow Parrot to move to git while maintaining link backwards-compatibility.  The first option is to use a single Git backend to Trac.  The second option is use Trac with multiple vcs backends, i.e. read-only for subversion and read-write for git.  
+
+== Trac with a Single Git Backend ==
+
+This space unintentionally left blank.
+
+== Trac with Multiple VCS Backends ==
+
+A small problem exists in the fact that Trac isn't meant to have multiple version control backends.  There's a solution:
  * [http://trac-hacks.org/browser/subprojectspatch/0.11/sub-projects.diff This tiny patch] allows a Trac project to have a sub-project.
  * The sub-project can be configured to use the same db as the parent project, propagating permissions and user info.
@@ -10 +18 @@
  * A more or less usable [http://trac-hacks.org/wiki/GitPlugin Git plugin] exists for Trac.
 
-Using these tools, here's the plan (as it exists):
+Using these tools, here's a possible plan:
  * Keep Subversion as the version control backend on the current Trac project (the parent).
  * Add a subproject (the child) which uses Git as the vc backend.
@@ -19 +27 @@
    * Make all navigation items in the child project point at the parent.
 
-This will allow Git and Subversion to integrate gracefully with Trac and will preserve links to Subversion revision numbers.  There are still some holes to fill in but that's more or less the plan.  I (cotto) will make sure all the pieces exist and can be made to fit together before seriously proposing anything.
+This would allow Git and Subversion to integrate gracefully with Trac and will preserve links to Subversion revision numbers.  There are still some holes to fill in but that's more or less the plan.  I (cotto) will make sure all the pieces exist and can be made to fit together before seriously proposing anything.
 
 remaining issues: