Archives
Categories
SubscribeBundles Repository Moved & Mirrored
A couple of important announcements went out over the TextMate mailing list related to revision control, affecting any users keeping up with the “bleeding edge” of bundle development.
Subversion Relocation
The URL of the main Subversion repository has been changed from the forgettable untypeable http://macromates.com/svn/Bundles/ to a much nicer http://svn.textmate.org/. We made this change a while ago, but we didn’t put in a redirect before because we weren’t sure the new server could handle the load (there were some problems with the first one). We are putting in the redirect now.
Subversion doesn’t handle this change gracefully (it will just report an error and fail), so anyone using svn to keep up with bundle development needs to manually update the checkout to the new location. Here are the steps required to relocate your checkout.
In the terminal:
# assuming this is where your old chekout is
cd /Library/Application\ Support/TextMate
svn switch --relocate \
http://macromates.com/svn/Bundles/trunk/ \
http://svn.textmate.org/trunk/
If you have “switched” subsets of the checkout, for example to test the “work in progress” (WIP) bundles, then this relocate command won’t fix the switched bundles. Run svn status in the root of your checkout, which will indicate any switched bundles with an “S” marker. For each switched bundle, find the from URL by changing directories into the bundle, and running:
svn info
This will show the URL on the second line. To make a to URL from that, just replace “macromates.com/svn/Bundles” with “svn.textmate.org”. We combine the from and to URLs when running the relocate command, for example:
cd Bundles/Subversion.tmbundle
svn switch --relocate \
'http://macromates.com/svn/Bundles/branches/Subversion%20(Interactive%20Input).tmbundle/' \
'http://svn.textmate.org/branches/Subversion%20(Interactive%20Input).tmbundle/'
(This was detailed in this mailing list post; instructions repeated here for convenience.)
Git for Bundle Development
For those developers who prefer distributed revision control, we’re now also mirroring the bundle repository on GitHub, at http://github.com/textmate/. This should make it much easier for you to customize your bundles and contribute back: just fork the bundle from GitHub, work on it locally, and then tell us when you have changes for us to pull back into the main repository. GitHub bundles will be kept in sync with the svn bundles, and changes to the main svn repository will be reflected at GitHub. As a bundle maintainer, you’ll be able to commit either to a fork of our GitHub bundle, or, as before, directly to svn. Anyone who isn’t a bundle maintainer will now also be able to work under version control.
For those existing authors without GitHub accounts, we used «nick»@svn.textmate.org as the commit email address. To link these changes to your account on GitHub so you’ll be properly credited (or blamed), just add that email to your account.
If you already forked a bundle obtained from svn, it would help us if you “rebase” that fork onto our GitHub mirror, as we carefully ensured proper history and author info for these mirrors. Also, our mirrors will serve as the starting point when looking for forks in the community. It is a bit of a nuisance to rebase all of these bundle forks, we realize, but it can be finished all at once, and will save pain later on. The sooner we can manage it, the better. To learn how to rebase your checkout, see Allan’s recent mailing list post.
This was initially intended as a two-way mirror (so that changes to the bundles in git would be reflected in svn as well), but the way git-svn works, we must rebase our “master” using the svn trunk, breaking the updates in one direction. So for now it is only a passive mirror. Practically, this means that when we pull changes, we must go through svn, so these changes will be given a new address (hash) and authorship info when they arrive in our master branch, requiring the fork we pulled from to do a new merge. We are looking into how to avoid this (and for this reason we are hesitant to pull changes right now: manually updating the dropped author info is tedious).
