Bundles 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).

17 Comments

  1. 26 Jun 2009 | # Jason Lee wrote…

    ha ha! I'm the first reviewer.

  2. 26 Jun 2009 | # Jason Lee wrote…

    I hope Textmate will have this feature: automatic backup my custom settings(Bundles,Hightlight Theme and the others…) to the some website,may it svn host or git host or Textmate official web service.

  3. 26 Jun 2009 | # saporro wrote…

    The GitHub URL is http://github.com/textmate/

  4. 26 Jun 2009 | # Jacob Rus wrote…

    saporro: Yes, it was a silly glitch that killed my URLs in the original post. It was fixed within a couple minutes. :-)

  5. 26 Jun 2009 | # Chad Humphries wrote…

    Thanks for the github mirror!

  6. 26 Jun 2009 | # August Lilleaas wrote…

    A good solution to the svn/git problem: get rid of svn altogether, and go full time Git ; )

  7. 26 Jun 2009 | # Yann wrote…

    I make a couple bundles (CSS/HTML additions) and some people have asked me if I could have them on the getbundle repo but I'm not sure how you're supposed to go about it.

    Is this info written somewhere and I missed it? Any pointer much appreciated.

  8. 26 Jun 2009 | # Jay wrote…

    This is indeed great news! Git is a wonderful way to work with code, and I'm trilled to see that TM is taking advantage of it.

  9. 26 Jun 2009 | # Sam Aaron wrote…

    Is there any motivation for keeping svn and not making github repository the canonical repository?

  10. 26 Jun 2009 | # Allan Odgaard wrote…

    Sam: There are a few reasons, yes. Leopard ships with svn not git, a user can do one command to checkout the full Subversion repository, but for Git he needs one command per bundle, and likewise for updating (and with Git’s requirements about current dir being the checkout, you actually need a script/loop to batch-update your checked out bundles), and I prefer not having to convert the entire Support folder to only one Git project, but the restructuring required here to do multiple (more appropriate) Git repositories is not feasible ATM.

    Long-term we likely will drop svn support, but not as long as SCM is invovled in the getting more bundles recipe.

  11. 27 Jun 2009 | # Allan Odgaard wrote…

    Yann: If you refer to the GetBundles bundle then you just need to follow the proposed naming convention, and your bundle will be found (indexing happens daily).

  12. 29 Jun 2009 | # Double Shot #484 « A Fresh Cup wrote…

    [...] Bundles Repository Moved & Mirrored – For TextMate bundles, that is. [...]

  13. 29 Jun 2009 | # Daily Links #3 | :neil_middleton wrote…

    [...] Textmate bundles have moved and it's now on GitHub! [...]

  14. 03 Jul 2009 | # @billifer wrote…

    Thank you for moving to Git (and GitHub)!! This makes, well, everything about bundle customization easier. As I'm not an official bundle developer, I don't have write access to the SVN repo, but the distributed nature of git (and having already kept my own code on GitHub) means that my forks of bundles can been treated by TextMate as just as authoritative as anyone else's. Fantastic.

  15. 09 Jul 2009 | # Greg wrote…

    Have you guys considered Bazaar for a DVCS (hosting on Launchpad). It has the nice advantage of allow for a more flexible repo style than Git, and has support for an SVN-style workflow too though its checkouts.

  16. 09 Jul 2009 | # tim wrote…

    Thanks' for the heads up Greg: Bazaar does indeed seem nice: Avoids the issue of needing a system that is widely installed by default (as it uses Python, which is installed by default on most OSs).

    There's a comparison of Bzr Vs Git makes some compelling (to me) arguments in terms of both power and ease of use.

    Good learning support too From the Bazaar in five minutes tutorial etc.

  17. 09 Jul 2009 | # Allan Odgaard wrote…

    I am sure each of the DSCM systems out there have their own set of compelling features.

    Our choice was more GitHub than it was Git as people were already mirroring/forking the svn bundles on GitHub (so we wanted to ensure they got a proper base, i.e. with all the development history and author credits).

    As implied in one of my previous comments I don’t think it is right that TM couples SCM and bundle distribution as close as it presently does, this is one of those “if it ain’t broke…” but definitely we will fix this for 2.0 so that it won’t seem like we dictate what SCM system you should use.

Comments closed, you can use the mailing list for discussion.