gsc earlier this week because it worked for me. If you were brave
and cloned the repository to try it out,
you undoubtedly found that, well, it didn’t work for you. Thanks to
Rob for reporting the problem with setup.py, as well as a few other bugs.
I’ve pushed an update to the repository on
gitorious which includes fixes for the
setup.py issue, support for some [likely] common Subversion
configurations and a test suite. In addition to the installation issue
Rob also reported that wasn’t able to clone his svn repository with gsc.
Some investigation led me to realize the following cases weren’t supported:
- svn:externals specified with nested local paths (ie, “vendor/product”)
- empty directories in the Subversion repository with nothing but
svn:externals set on them
Both now clone correctly.
One open question is what (if anything) gsc should do when you run it
against an already cloned repository. I’ve envisioned it purely as a
bootstrapping tool but received an email stating that it didn’t work
when run a second time, so obviously it should do something, even if
that’s just failing with an error message.
|tags:||cc, git, git-svn, gsc, svn, svn:externals
UPDATE I’ve pushed a few bug fixes; see this
entry for details.
At Creative Commons we’re a
dual-[D]VCS shop. Since we started
last year we’ve been using both
and git. The
rationale was pragmatic more than anything else: we have lots of code
spread across many small projects and don’t have the time (or desire) to
halt everything and cut over from one system to the other. This approach
hasn’t been without it’s pain but I think that overall it’s been a good
one. When we create projects we tend to create them in git and when we
do major refactoring we move things over. It’s also given
[STRIKEOUT:recalcitrant staff] me time to adjust my thinking to git.
Adjustments like this usually involve lots of swearing, fuming and muttering.
As I’ve become more comfortable with git and its collection of support
tools, I’ve found myself wanting to use git
work on projects that remain in Subversion. One issue I’ve run into is
our reliance on svn:externals. We use externals extensively in our
repository which has generally made it easy to share large chunks of
code and data, and still be able to check out the complete dependencies
for a project and get to
work_. More than
once I’ve thought “oh, I’ll just clone that using git-svn so I can work
on it on the
plane_,” only to
realize that there are half a dozen externals I’d need to handle as well.
Last week I decided that tools like
magit make git too useful
not to use when I’m coding and that I needed to address the “externals
issues“. I didn’t want to deal with a mass conversion, I just wanted
to get the code from Subversion into the same layout in git. I found
git-me-up which was
close, but which baked in what I assume are Rails conventions that our
projects don’t conform to. Something like this may already exist, but
the result of my work is a little tool,
**gsc** — “git subversion clone”.
gsc works by cloning a Subversion repository using git svn and then
recursively looks for externals to fetch. If it finds an external, it
does a shallow clone of the target (only fetching the most recent
revision instead of the full history). The result is a copy of your
project you can immediately start working on. Of course, it also
inherits some of the constraints associated with svn:externals. If
you want to work on code contained in an external (and push it back to
the Subversion repository) you may need to check out the code
course, the beauty of DVCS is that there’s nothing stopping you from
committing to the read-only clone locally and then pushing the changes
to a reviewer.
You can grab gsc from gitorious. There are
also installation instructions and basic usage information in the
|tags:||cc, git, git-svn, gsc, svn, svn:externals
out. Reading feeds on my flight from IND to PHX this afternoon I ran
across the WordPress Automatic Upgrade
(shouldn’t that be the Automattic?). Nice, but I’d like to plug my
approach to managing WordPress upgrades, which I think is even easier,
assuming you’re OK with minimal command-line interaction.
First, install WordPress from a Subversion checkout; do:
“ $ svn co http://svn.automattic.com/wordpress/tags/2.6/“
instead of downloading the .zip or .tar.gz file. Configure as directed.
Then, when a new version is available, log into your webhost and run:
“ $ svn switch http://svn.automattic.com/wordpress/tags/2.6.1/“
from your install directory.
Note that you can also do something similar (but an order of magnitude
more complex, at least for my brain) using
if you want to version your local settings as well. Perhaps one day
Asheesh or I will get that written up.
|tags:||git, subversion, upgrade, version control, wordpres
In an attempt to prevent additional
git (or maybe just
git-svn?) induced PTSD,
Asheesh kindly created a git
phrasebook. If you,
too, are a
deserter and want to figure out how the whole branching thing works in
git, this may be useful to you.
Someday I’ll write up my thoughts on distributed version control and
“convention versus configuration”, which seem to overlap in this
deployment. But not today.
|tags:||cc, git, ptsd