Package: git-svn-helpers
git-svn-helpers is a collection of command line tools that greatly simplify
using git for svn repositories.Its main goal is to make setting up a local git repository following an
existing svn checkout a ‘no-brainer’.It also addresses using a single git-svn repository for working on multiple
checkouts of (usually) different branches and switching between them.Basic usageExecutive summary:> cd path/to/svn/repo
> gitify initPerform local changes and commit them to git. When ready to push your changes:> gitify pushTo update your working directory with upstream changes:> gitify updategitify will take care to keep your git and svn repository in sync and do its best to avoid conflicts when updating.Sample sessionHere’s a sample session:> cd /tmp
> svn co https://svn.plone.org/svn/plone/plone.app.form/branches/1.1 plone.app.form
A    1.1/setup.py
...
Checked out revision 27228.
> cd plone.app.form
> gitify init
No git repository found in /Users/tomster/.gitcache/.
Initiating cloning into cache.
Analyzing svn log...
Cloning https://svn.plone.org/svn/plone/plone.app.form/ from r10593:34543 into /Users/tomster/.gitcache/
Initialized empty Git repository in /Users/tomster/Development/gitcache/plone.app.form/.git/
...
Git branch 'local/1.1' is now following svn branch '1.1':
# On branch local/1.1
nothing to commit (working directory clean)
> git branch
* local/1.1
  masterPoints to note:gitify limited the cloning to the revisions found in the svn log of the package root (herehttps://svn.plone.org/svn/plone/plone.app.form/). A big time saver, especially on large repositories (such as plone.collective)gitify created a local branchlocal/1.1that follows the (remote) svn branch1.1and switched to itgitify assumed that the name of the package is the name of the directory it
was called from (in this caseplone.app.form) as it refuses to guessMultiple check-outs of the same packageIn practice you will often work with different local copies of a given repository, i.e. on trunk and on a feature branch. That’s when the.gitcachedirectory created above comes in handy. Let’s move our previous checkout out of the way and create a maintenance checkout that follows trunk:> cd ..
> mkdir feature-branch
> mv plone.app.form feature-branch/
> mkdir maintenance
> cd maintenance/
> svn co https://svn.plone.org/svn/plone/plone.app.form/trunk plone.app.form
A    plone.app.form/setup.py
...
 U   plone.app.form
Checked out revision 27228.What happens if we run gitify here?:> cd plone.app.form/
> gitify init
Updating existing cache:
fetching /Users/tomster/.gitcache/plone.app.form
Done. 1 packages updated.
Git branch 'local/trunk' is now following svn branch 'trunk':
# On branch local/trunk
nothing to commit (working directory clean)Notice, that this operation went much faster, as we now have used the existing git repository in the cache directory, thus avoiding the slow and network intensive clone operation.This can be further evidenced by looking at the available local branches now. Notice how the git repository contains both trunk and the 1.1 branch:> git branch
  local/1.1
* local/trunk
  masterSwitching branchesIf the svn repository switches to another branch (i.e. due to a change in svn:externals or in a buildout source) the branch git is on differs from the current svn branch. To remedy this you can either manually switch git or just re-rungitify init:> svn info
URL: https://svn.plone.org/svn/plone/plone.app.form/trunk

> git branch
  local/1.1
* local/trunk
  masterIf we switch the svn branch, git initially doesn’t catch the change and the branches differ:> svn switch https://svn.plone.org/svn/plone/plone.app.form/branches/1.1
> svn info
URL: https://svn.plone.org/svn/plone/plone.app.form/branches/1.1

> git branch
  local/1.1
* local/trunk
  masterAfter re-runninggitify initthey are the same again:> git branch
* local/1.1
  local/trunk
  masterKeeping the cache up-to-dateOf course, once you introduce a cache you need to keep it up-to-date.git-svnprovides thefetchcommand for this purpose. In practice it is cumbersome
to update each package manually, though. Therefore we provide our ownfetchcommand which can update multiple packages at once using wildcards, like so:> gitify fetch plone*
fetching /Users/tomster/.gitcache/plone.app.form
fetching /Users/tomster/.gitcache/plone.pony
fetching /Users/tomster/.gitcache/plonenext
Done. 3 packages updated.You can pass the-voption to see the output of thegit-svnfetchcommands.
If you don’t provide a packageallpackages will be updated.Note, that the our fetch command never touches any working copy, only the cache.
Is primarily intended to be run as a maintenance command, i.e. via crontab to keep
the local cache ‘fresh’.Keeping git and svn in syncSince the local filesystem is both a git repository, as well as a svn check-
outat the same time(IOW we have both.gitand.svnfloating
around) they should be kept in sync as closely as possible. By design, this
can only happen, when we have online access to the svn repository. Therefore
it is best performed when committing back to svn. The way this is achieved
manually is to first dcommit and then perform asvn up--forcecommand
(the--forceis necessary so that svn won’t be bothered by any new files
that have been committed).gitify pushprovides a convenience command that
performs this for you:> gitify push -v
Committing to https://svn.plone.org/svn/plone/plone.app.form/branches/1.1 ...
At revision 27229.
INFO: Pushed local changes to svn.
> svn st
<BLANKLINE>InstallationSimply useeasy_install,
optionally withvirtualenv:> easy_install git-svn-helpersRequirementsgit-svn-helpersrequires that git (with subversion support a.k.agit-svn) is already installed.TODOadd support for custom svn layoutChange history0.9 - 2012-03-11The cannonical repository is now inhttps://github.com/collective.
[rossp]Fix the handling when switching to a svn branch that git already has
a local branch for.
[rossp]0.8 - 2010-03-10Make the init command follow along if the svn repository has been switched
to another branch. Thanks to Calvin Hendryx-Parker for reporting the issue.
[tomster]0.7 - 2010-03-07Use full copies instead of symlinks to create working copies. This avoids
the issue of having the git and svn repository out of sync when working
with multiple copies of the same repository and greatly reduces the risk of
conflicts.This also means, that the fetch command now only operates on the cache
without modifying the working copy (making it safe to run via crontab,
for example)Running gitify against an old-style working copy will produce an error.
Simply deleting the symlink and re-running gitify remedies that, however.Another effect, is that the init command is now only needed once for each
working copy (it is no longer necessary to re-run the command after
switching between different working copies of the same repository).gitify therefore no longer defaults to the init command (just as neither
git nor svn do anything w/o supplying an explicit action). Also, it has been
renamed fromgitify(back) toinit.
[tomster]Allow thehelp,--versionandfetchcommands to run outside .svn directories
[tomster]0.6 - 2010-03-07add a file manifest so that all necessary files will get included for sdist
[proyvind]sample update hook for enforcing dcommits to help keeping the svn and git
repositories in sync
[chaoflow]updated tests to work with git 1.6.x
[tomster]removed deprecated entry points for clone, fetch and commit
[tomster]0.5 - 2009-08-15 (a.k.a. HAR2009 release)Addedgitify updatecommand, which performs a git-svn rebase operation
for the current svn checkout but also handles uncommitted local changes
gracefully (unlikegit svnbut like svn does)No longer use the logging module for user feedback. That idea was rather
misguided :)0.4 - 2009-08-11Refactored the entry points to just use gitify. All other commands are now
sub-commands ofgitify:gs-commithas been replaced withgitify pushgs-fetchhas been replaced withgitify fetchAdded usage and help output for each command.Removed thegs-cloneentry point as it was only ever used together with
the main gitify command anyway.Use proper logging instead of just printing to stdoutAdded comprehensive tests, including functional tests that cover the entire
update/commit cycle of cloning an svn repository and commiting back to it.0.3.1 - 2009-07-09BUGFIX: Don’t use custom aliases, as they might not be installed.
This resolveshttp://github.com/tomster/git-svn-helpers/issues#issue/2BUGFIX: Explicitly list elementtree as dependency
This resolveshttp://github.com/tomster/git-svn-helpers/issues#issue/1)0.3 - 2009-06-09Added thegs-commitcommand which helps committing back to svn and
keeping git and svn in sync0.2b - 2009-06-05Added thegs-fetchcommand which helps keeping the cache up-to-date0.1b2 - 2009-05-30BUGFIX: get the svn log from the package root (i.e./path/to/foo)
instead of the locally checked out path (i.e.path/to/foo/branches/bar)
which is usually much younger than the entire package and thus we would miss
revisions in the cloning process!0.1b1 - 2009-05-30Initial release a.k.a. “Works for me”Download