Hi all, What is the procedure for making a new (small) new language bundle available?
Add to the SVN? (need privileges, of course) Host it oneself?
I'd mostly in the first place just like an SVN I can access from home and work as it incrementally builds to something more useful.
I googled bundleforge (distant memory that that was an open place for bundles, but it says come back soon?
t
On 2. Aug 2007, at 17:41, Timothy Bates wrote:
What is the procedure for making a new (small) new language bundle available?
Add to the SVN? (need privileges, of course)
The procedure to get it into the official repository is to make the bundle available then I can add it under Review generally with a bunch of review comments and when that is addressed it will be moved to non-review.
Host it oneself?
I’ve wanted to write up something about this for some time now, but basically I want to get away from the centralized repository we currently have -- it puts all the administrative work on me (including judging what should be public etc.), and makes it too easy for people with too broad commit access to mess with bundles w/o first discussing the changes. At the same time it makes it difficult for people w/o commit access to contribute (and/or results in non- committers sending me a “replacement bundle” for something hosted, and leaves it up to me to track what was actually changed, and to check if the “replacement” was based on the latest bundle we had in the repository).
The solution I am pondering is switching to a distributed version control system (like git or mercurial). This has a few advantages such as allowing people w/o commit access to still do regular commits to the bundle they work on (applied to their local clone of the bundle).
Later they can either send the commits to the bundle maintainer or decide to simply make their bundle public. Because of how these version control systems are designed, it is no problem to initially clone e.g. the Blogging bundle from Brad Choate (which he would have made public), and then later switch to fetching updates from Brett Terpstra. Or maybe I would clone Brad’s version, make that public under the bundles.macromates.com domain, and when Brett makes his continued work public, I can cherry-pick some of his improvements for the bundle I am making public -- the user of course could decide to clone my bundle, and track my updates, but also himself cherry-pick some of Brett’s improvements that I didn’t pick.
IOW these (distributed) systems are designed to *not* have a single authority (which is ideal for bundles since many of the bundles have seen a change in primary maintainer) and they are designed to keep *all* the history (which is good because our bundles generally have many contributors, and sometimes one contribution (i.e. one patch I receive) is actually many changes, for which it would be nice to have the full history).
Also, rather than sending a patch to the maintainer, ideally the contributor makes his bundle public, and tells the maintainer to pull from that. In practice the maintainer of a bundle will have a public version and a local version, those are mostly in sync, and he pushes from his local clone to the public, and when a contributor tells him that the contributor has a change, the maintainer pulls from the contributors public bundle -- the maintainer can test that, and say there are some problems, he can fix those, push it as a branch to his public bundle, and ask the contributor to update to that, and go through his changes, and when the contributor okays the fixes, the maintainer merges the branch into master (here the contributor could again commit to the work-in-progress, lather, rinse, repeat).
The advantage here is a) it is simpler to exchange these “work in progress” patches, and b) all history is preserved. Also, while a feature is being developed, users can select to follow those changes, even though they do not happen in the “official” bundle (a bit like what we have recently started to do by using svn branches, just not sucking as much wrt branch handling ;) ).
The reason I am still hesitant to switch though is:
1. If we make it completely distributed, we still need a central list of bundles and an easy way to grab them (so need to work out a system for that).
2. While there are free DSCM hosting solutions, it would probably be good if I created one, as I think it would be ideal to have just one or two people able to commit to a bundle (and I’d rather not encourage cluttering the existing hosting services with TM bundles). So e.g. for the LaTeX bundle, both Brad, Haris, and Robin would each have their own bundle, and probably I would link to Haris’ as the official one, which Brad and Robin will track, and Haris will integrate their improvements as he sees fit.
3. Learning curve; already some users are not too happy about the current reliance on svn, so I expect some resistance if switching to something even more alien. Also, the idea is that it will make it easier to contribute, which includes doing local commits, but often people do not realize that they want to contribute before after they have done many changes -- so I would like this to somehow be integrated, i.e. all bundles included with TM are clones and have full repository info, and each change you make in the bundle editor asks you for a commit message, and does a commit behind-the-scenes, which would also mean ditching my tmDelta system and simply rely on the version control system to figure all this out -- but all this is easier said than done, and I am not sure it is worth bothering all users with this.
4. Sometimes we make batch changes to all bundles, e.g. when me moved the ruby plist bundle to osx/plist -- if we distribute the system, such batch changes are not really possible. Some goes for Michael’s work standardizing scope names. He would have to clone all bundles, work on these, and then ask all the maintainers to pull his changes (or give him push/commit access).
Comments about this subject encourages! :)
On Aug 3, 2007, at 11:00 PM, Allan Odgaard wrote:
The solution I am pondering is switching to a distributed version control system (like git or mercurial). This has a few advantages such as allowing people w/o commit access to still do regular commits to the bundle they work on (applied to their local clone of the bundle).
More information on distributed version control system -- git. Linus Torvalds' Google Tech Talk: http://www.youtube.com/watch?v=4XpnKHJAok8
I don't think there will be any conflict of having a svn and a git at the same time. We have a subversion server for the default bundles that comes with TM, and various git servers for the bundles that are not included in the default distribution.
I have not tried git or mercurial, so I can not really comment if this would help with the process of the development. Linux Torvalds, who I imagine to be smart guy, seems to be pretty confident about the distributed model.
ip
On 4. Aug 2007, at 07:12, Ivan Pan wrote:
On Aug 3, 2007, at 11:00 PM, Allan Odgaard wrote:
The solution I am pondering is switching to a distributed version control system (like git or mercurial). This has a few advantages such as allowing people w/o commit access to still do regular commits to the bundle they work on (applied to their local clone of the bundle).
More information on distributed version control system -- git. Linus Torvalds' Google Tech Talk: <http://www.youtube.com/watch? v=4XpnKHJAok8>
I was doing something else while watching it, so I only got half of it, but it seemed mainly focused on telling how great Linus is and how bad CVS is.
A good short introduction to decentralized version control can be found here: http://www.selenic.com/mercurial/wiki/index.cgi/ UnderstandingMercurial
Fraser Speirs wrote about the git architecture, which may also prove useful for understanding the model (mercurial and monotone has a similar underlying architecture): http://speirs.org/2007/07/19/a- subversion-user-looks-at-git/
I don't think there will be any conflict of having a svn and a git at the same time. We have a subversion server for the default bundles that comes with TM, and various git servers for the bundles that are not included in the default distribution.
If I adopt a decentralized system, I do not plan to keep the existing svn server. The idea is to get away from it, even for default bundles.
On Aug 4, 2007, at 12:39 AM, Allan Odgaard wrote:
I was doing something else while watching it, so I only got half of it, but it seemed mainly focused on telling how great Linus is and how bad CVS is.
One of things about video and audio podcast is that you can not really skip to the point, especially the speakers like to ramble on. His points were better expressed when people started asking him questions.
If I adopt a decentralized system, I do not plan to keep the existing svn server. The idea is to get away from it, even for default bundles.
I can not remember when Linus started talking the distributed model. The idea was he collected patch submissions from various developers that he trusts and he released the kernel source that everyone pulls from. I would imagine if you do move away from a centralized server, your bundles, a.k.a. the default ones, would be what majority of us pulls from. You probably don't need svn servers anymore.
Looking forwards to see how this model will turn out.
ip
On Aug 4, 2007, at 12:00 AM, Allan Odgaard wrote stuff about things.
Obviously the ideal plan would be to have transparent git commits and merges and updates all happening seemlessly in the background any time you interact with bundles. The auto-update system would have to let you automatically update your bundles somehow too.
The trick is how we get from where we currently are to where we need to be. I think we can make baby steps in the meantime to ease our way into the ideal.
Just think about the ways people currently deal with bundles:
1. Use only the bundles you get from inside TextMap.app when you download the latest version. 2. Download bundles in zip files, double-click to install. All local changes go into tmdeltas. 3. Manually checkout all or individual bundles and the support folders. All local changes either go into deltas or the bundles themselves. 4. Use GetBundles to do #3 for you.
Switching to git won't really change much of anything in the short term. And you should be able to ramp up and make it completely first class integrated for TM2.
Switching from Subversion to git:
1. No change 2. No change 3. Manually checkout with git instead. Nerds will figure it out. 4. Update GetBundles to use git instead.
Until TM2 comes out, you should keep the subversion repo up and running. Just gradually convert each tmbundle into a git checkout/repo (.git folder in the root of the project?) and commit that to the subversion repo. Then as people keep updating their bundles, their bundles get upgraded in the background without them ever knowing about it. Eventually we remove all the .svn folders and turn off the server. Once that happens you should have something in TM2 to handle the updates from that point on. You'll also have to think of something to do about the tmdeltas once that happens. Have fun with that.
Obviously, for anything that gets included with the TextMate app itself, there is going to have to be a single source that you pull from. Either your own git branch merged from other peoples or just pulling from them directly with no merging.
Until TM2 comes out, all us nerds should be happy updating and committing our bundles to a central subversion repo or upgrading them to git and pulling from a central source. But once TM2 comes out, it should integrate all that stuff right into the app itself.
I can hardly wait to upgrade all my bundles to git.
thomas Aylott — subtleGradient — CrazyEgg — sixteenColors
On 4. Aug 2007, at 09:42, Thomas Aylott (subtleGradient) wrote:
[...] Switching to git won't really change much of anything in the short term. And you should be able to ramp up and make it completely first class integrated for TM2.
Switching to a distributed version control system (DSCM) is not motivated by the user experience but rather the development/ contribution process (and removing my role as gatekeeper / janitor) -- and something I would like to do as soon as I am convinced one of the existing DSCM systems is the right choice, not couple this with TM2 in any particular way.
It would be great if TM itself can use the DSCM to maintain bundle changes locally -- how realistic that is, I am not really sure though.
Without wishing to turn this into a which scm is best discussion, git isn't the easiest system for non-technical users to learn - it is aimed at power users. You may end up with a situation where using the version control is harder then creating the bundle. I've not used mercurial much but I know thats meant to be simpler than git, I have used bzr which i've found dead simple and quite like subversion, and it branches happily from subversion. I'm sure theres other possibilities.
--- jebw
On 5 Aug 2007, at 05:55, Allan Odgaard wrote:
On 4. Aug 2007, at 09:42, Thomas Aylott (subtleGradient) wrote:
[...] Switching to git won't really change much of anything in the short term. And you should be able to ramp up and make it completely first class integrated for TM2.
Switching to a distributed version control system (DSCM) is not motivated by the user experience but rather the development/ contribution process (and removing my role as gatekeeper / janitor) -- and something I would like to do as soon as I am convinced one of the existing DSCM systems is the right choice, not couple this with TM2 in any particular way.
It would be great if TM itself can use the DSCM to maintain bundle changes locally -- how realistic that is, I am not really sure though.
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 6. Aug 2007, at 17:10, Jeremy Wilkins wrote:
Without wishing to turn this into a which scm is best discussion, git isn't the easiest system for non-technical users to learn - it is aimed at power users. You may end up with a situation where using the version control is harder then creating the bundle. I've not used mercurial much but I know thats meant to be simpler than git, I have used bzr which i've found dead simple and quite like subversion, and it branches happily from subversion. I'm sure theres other possibilities.
I was careful not to mention any system in particular :)
Git from a usability POV is indeed frustratingly (and unnecessarily) complex.
On Aug 6, 2007, at 12:11 PM, Allan Odgaard wrote:
On 6. Aug 2007, at 17:10, Jeremy Wilkins wrote:
Without wishing to turn this into a which scm is best discussion, git isn't the easiest system for non-technical users to learn - it is aimed at power users. You may end up with a situation where using the version control is harder then creating the bundle. I've not used mercurial much but I know thats meant to be simpler than git, I have used bzr which i've found dead simple and quite like subversion, and it branches happily from subversion. I'm sure theres other possibilities.
I was careful not to mention any system in particular :)
Git from a usability POV is indeed frustratingly (and unnecessarily) complex.
I have been using darcs for a while, and when it works it is quite cool. It can be used concurrent with svn (eg use both darcs and svn on the same tree) and is rather easy (almost intuitive) to use.
But it has two rather big drawbacks:
1. It is written in Haskell, and getting Haskell to run on OS X is slightly trying. 2. If you ever browse it's directory (_darcs, so not hidden) with the Finder, it chokes badly on any .xxx files the Finder may leave behind.
Gerd
I don't think I follow everything in the thread, but Git seems to be very difficult to normal users. Git isn't as popular as svn. Subversion has an excellet free book available, and many other 3rd party manuals for svn. Subversion also has some GUI clients, which makes many people's lives easier.
Adapting another version control system may well be worth for all of us in the end. However, educating people to adapt the new system and introducing git for those have no experience with any version controls as their very first version control sytem might increase the burden of support and mailing list.
Takaaki
I think it is not a good idea to switch to a distributed model for the Bundles. There are just 36 Bundles out of 152 which are really official and get shipped with TM, the others are optional. The way to go is not to switch the source control system. We should think about the distributing process. I think there should be no source control information in the Bundles the user installs. I think we should let decide each maintainer what he wants to use and just give a solution to make the bundle public. A small web app would do the trick.
There could be two options for a Bundle maintainer: 1) i have no source control... i upload ZIP's 2) i have svn (or what ever)... please checkout/export my source when i ping you with a special token and zip it for me. (the ping could be done by a simply hook or manualy)
The client side should be no problem because i think most ordinary users use the GetBunlde and to switch the installing and updating process will be no problem. The version control will be don be the web app. Also it should be possible to give the Bundle a status like "beta", "use at your own risk"...
Basti
On 06.08.2007, at 19:40, Gerd Knops wrote:
On Aug 6, 2007, at 12:11 PM, Allan Odgaard wrote:
On 6. Aug 2007, at 17:10, Jeremy Wilkins wrote:
Without wishing to turn this into a which scm is best discussion, git isn't the easiest system for non-technical users to learn - it is aimed at power users. You may end up with a situation where using the version control is harder then creating the bundle. I've not used mercurial much but I know thats meant to be simpler than git, I have used bzr which i've found dead simple and quite like subversion, and it branches happily from subversion. I'm sure theres other possibilities.
I was careful not to mention any system in particular :)
Git from a usability POV is indeed frustratingly (and unnecessarily) complex.
I have been using darcs for a while, and when it works it is quite cool. It can be used concurrent with svn (eg use both darcs and svn on the same tree) and is rather easy (almost intuitive) to use.
But it has two rather big drawbacks:
- It is written in Haskell, and getting Haskell to run on OS X is
slightly trying. 2. If you ever browse it's directory (_darcs, so not hidden) with the Finder, it chokes badly on any .xxx files the Finder may leave behind.
Gerd
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
I vote for promoting "get bundle" to a normal part of the application, a major and clearly marked feature, not an adjunct plugin.
Getting bundles of functionality is not merely a "nice thing" in TextMate. It is the very essence of TextMate. The process of retrieving and managing bundles should be an absolute first class experience. I'd say my ideal would be something like Quicksilver's plugin system.
Short of actually editing text, managing plugins is the most important thing I do with the app.
I think *distribution* should have absolutely nothing to do with version control, under the assumption that whatever system is selected, it presumes the user will have it present on their system.
Of course, this is all moot re: how developers manage code for their plugins. Having considered this situation at my own company, the benefits of distributed source control are transparently obvious to me.
But that should be orthogonal to distribution to users. I really hate the whole "let's just do an svn checkout to get stuff" concept, and I understand perfectly how to do it.
-andre
It's obvious that we all agree that there should be a simple transparent system for Discovering, Updating and Editing bundles. It doesn't necessarily have to be built into TextMate.app itself in order for it to feel transparent and simple.
The other side of the coin is the Bundle Developer side. The system should make it seamless for hardcore bundle developers to develop bundles locally and then share those bundles with the world. The system should also allow and encourage novice and beginner users to make bundles for themselves and share them with the world. And also allow anyone to do bug fixes on any bundle and share that fix.
And all of that should be possible without having to get approval from anyone.
Obviously the "official" bundles that are distributed with TextMate should still be verified by someone, but we need to take all the burden of verifying the quality and compatibility of the bundles off of Allan.
The technical side of how to actually go about doing that doesn't matter nearly as much.
thomas Aylott — subtleGradient — CrazyEgg — bundleForge
I think I'd vote against a full-blown bundle administration feature for textmate. The included bundles are enough for probably 80% of people, they are updated regularly with Textmate's major/minor/cutting-edge updates.
But it's clear that SOMETHING more than the current ad-hoc system for third party bundles is needed.
Perhaps TM could use the 'txmt' url scheme to install bundles? Then, we could have bundles.textmate.com as a cpan/python cheeseshop/rubygems web page with links that automatically install bundles? Seems like it wouldn't be too hard to implement a tm-command that could check versions on the locally installed bundles that could pull from this web page. This web page wouldn't even necessarily be required to host the bundles. Perhaps just official bundles would be physically hosted on this domain. But third-parties could at least create an entry with a "txmt" link to their bundle. Or maybe if the domain could host bundles, we could put a "Publish Bundle" button in the Bundle Editor, that would pop the bundle online.
I've been looking at mercurial and it's nice! I have two computers, and switch back and forth between them from day to day, all while editing two checkouts of the same svn repository. what a pain in the butt when I have to try and commit and I bump into conflicts. The documentation is really good, which is important!
I don't think most of us will have too much trouble picking up mercurial or git. However, new users (the same ones who struggle with svn) will likely have problems. I can't see how these problems would be anymore severe than learning svn.
Glad we're talking about all of this, –Alex
On 06.08.2007, at 22:54, Andre Behrens wrote:
I vote for promoting "get bundle" to a normal part of the application, a major and clearly marked feature, not an adjunct plugin.
Getting bundles of functionality is not merely a "nice thing" in TextMate. It is the very essence of TextMate. The process of retrieving and managing bundles should be an absolute first class experience. I'd say my ideal would be something like Quicksilver's plugin system.
Short of actually editing text, managing plugins is the most important thing I do with the app.
I think *distribution* should have absolutely nothing to do with version control, under the assumption that whatever system is selected, it presumes the user will have it present on their system.
Of course, this is all moot re: how developers manage code for their plugins. Having considered this situation at my own company, the benefits of distributed source control are transparently obvious to me.
But that should be orthogonal to distribution to users. I really hate the whole "let's just do an svn checkout to get stuff" concept, and I understand perfectly how to do it.
I strongly second all of this. I can't say much about the bundle development/administration process itself, since I never did any contribution to that. -- But from a *user perspective*, getting additional (or updated) bundles should be as transparent and "non- technical" as possible. I understand that a lot of TextMate users are technically very savvy, but all the same it would be nice if adding bundles would be handled over some kind of GUI (be it GetBundle or something integrated in the bundle manager) which doesn't depend on the user installing additional software like svn or any other version control system. So I vote for a strong separation between how the adding of additional bundles and how the bundle development/ administration is handled.
Best, Oliver
I have ten minutes before they close boarding for my plane, so excuse my top-posting, but:
This thread is *not* meant to be about the user experience wrt bundles -- I have already commented on that in the past (and of course I agree it is a very central part of TM and it should be better), it is *all* about the development process of bundles, which presently is suboptimal -- Thomas gave some of the points related to this.
I vaguely brushed the thought of using DSCM for local administration of bundles because it could be an advantage -- but that is not the central issue, and I am aware that just bundling git or hg with TM and expect the user to fiddle around in the shell to work on bundles, is not the way to do it.
On Aug 7, 2007, at 10:26 AM, Oliver Hagmann wrote:
On 06.08.2007, at 22:54, Andre Behrens wrote:
I vote for promoting "get bundle" to a normal part of the application, a major and clearly marked feature, not an adjunct plugin.
Getting bundles of functionality is not merely a "nice thing" in TextMate. It is the very essence of TextMate. The process of retrieving and managing bundles should be an absolute first class experience. I'd say my ideal would be something like Quicksilver's plugin system.
Short of actually editing text, managing plugins is the most important thing I do with the app.
I think *distribution* should have absolutely nothing to do with version control, under the assumption that whatever system is selected, it presumes the user will have it present on their system.
Of course, this is all moot re: how developers manage code for their plugins. Having considered this situation at my own company, the benefits of distributed source control are transparently obvious to me.
But that should be orthogonal to distribution to users. I really hate the whole "let's just do an svn checkout to get stuff" concept, and I understand perfectly how to do it.
I strongly second all of this. I can't say much about the bundle development/administration process itself, since I never did any contribution to that. -- But from a *user perspective*, getting additional (or updated) bundles should be as transparent and "non- technical" as possible. I understand that a lot of TextMate users are technically very savvy, but all the same it would be nice if adding bundles would be handled over some kind of GUI (be it GetBundle or something integrated in the bundle manager) which doesn't depend on the user installing additional software like svn or any other version control system. So I vote for a strong separation between how the adding of additional bundles and how the bundle development/administration is handled.
Best, Oliver
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
Jeremy Wilkins wrote:
Without wishing to turn this into a which scm is best discussion, git isn't the easiest system for non-technical users to learn - it is aimed at power users. You may end up with a situation where using the version control is harder then creating the bundle. I've not used mercurial much but I know thats meant to be simpler than git, I have used bzr which i've found dead simple and quite like subversion, and it branches happily from subversion. I'm sure theres other possibilities.
Git has been improving very rapidly though. It is vastly easier for normal (non-power-) users than it was a year ago, and I imagine it will be still better in another year. I don't know if you've tried Git recently; if not you should give it a try. If you stick to the basics, I'd say it's about as easy as SVN. But there's of course a lot of extra power there too, if you want it.
-Jacob
On 8/6/07, Jacob Rus jacobolus@gmail.com wrote:
Jeremy Wilkins wrote:
Without wishing to turn this into a which scm is best discussion, Git isn't the easiest system for non-technical users to learn - it is aimed at power users. You may end up with a situation where using the version control is harder then creating the bundle. (..)
Git has been improving very rapidly though. It is vastly easier for normal (non-power-) users than it was a year ago, and I imagine it will be still better in another year. I don't know if you've tried Git recently; if not you should give it a try. If you stick to the basics, I'd say it's about as easy as SVN. But there's of course a lot of extra power there too, if you want it.
-Jacob
There has been a lot of hype about Git lately and I don't understand why. I'm glad Allan consider Mercurial too, unfortunately some people respond "Ok, let's use Git". ;)
I read Git have slightly better performances than Mercurial, but as mercurial repos handle the complete OpenSolaris and Mozilla source trees just fine, I guess it would be good enough for the bundle repo.
Beside that, what are the advantages of Git over Mercurial? (And no, being initiated by Linus doesn't count ;)
Here are some advantages of Mercurial over Git I can see:
- Git is much more difficult to install than Mercurial. Even with MacPorts: e.g. Git needs new versions of openssh, openssl, curl, rsync, etc. and install more than 135 different commands! This take a lot of time and can be difficult if you have installed some of those outside of MacPorts. On Tiger, the only thing you need before installing Mercurial is upgrading Python to 2.4+. Then it takes 20 sec.
- Documentation: Git install a man page for each command (~135) and have no user manual, not the easiest way to find information when you need it, IMO. Mercurial has 3 man pages and complete doc, check the [official site][1] and the unofficial [hg book][2] (check the comparison between Mercurial and other systems, BTW).
- I consider myself a power user and Git is definitely more difficult to learn and use than Mercurial. The all "index tree" concept adds unneeded complexity, IMHO. (Allan has a hard time making a Git bundle for TM because of that. See the [qit bundle thread][3].) I think that if git is chosen for TM bundles, there will be more git related questions on this list than anything else.
- I read that a Git repository requires frequent manual "repacks" of its metadata. Mercurial repository needs no maintenance.
- AFAICT, Mercurial's source code is MUCH more clean and readable (and I'm not a big fan of Python).
The Mercurial bundle could be improved, and I guess there would be more people contributing if TM uses Mercurial, but it's working fine like it is now. (I'll commit a bunch of fixes and improvements soon BTW.)
@Jacob: I understand Git is improving rapidly, but so is Mercurial...
All I meant to say was: Be sure to compare both systems.
[1]: http://www.selenic.com/mercurial/wiki/ [2]: http://hgbook.red-bean.com/ [3]: http://lists.macromates.com/pipermail/textmate/2007-August/021412.html
-- FredB
On 8/6/07, Fred B fredb7@gmail.com wrote:
On 8/6/07, Jacob Rus jacobolus@gmail.com wrote:
Jeremy Wilkins wrote:
Without wishing to turn this into a which scm is best discussion, Git isn't the easiest system for non-technical users to learn - it is aimed at power users. You may end up with a situation where using the version control is harder then creating the bundle. (..)
Git has been improving very rapidly though. It is vastly easier for normal (non-power-) users than it was a year ago, and I imagine it will be still better in another year. I don't know if you've tried Git recently; if not you should give it a try. If you stick to the basics, I'd say it's about as easy as SVN. But there's of course a lot of extra power there too, if you want it.
-Jacob
There has been a lot of hype about Git lately and I don't understand why. I'm glad Allan consider Mercurial too, unfortunately some people respond "Ok, let's use Git". ;)
I'm surprised you took that as an attack on mercurial as an option both are fast moving projects and what is true today probably will change at least a little over the next few months. There are plenty of reasons Git has "buz" and it isn't a negative thing. Likewise for Mercurial, I don't see as much here but it is definitely buzzing in the same sense. In fact, I think those communities seem to be growing with each other swapping ideas back and forth while pushing things like performance to a new level.
I don't think any decision would really please everyone but one idea I did have was the possibility of mirroring between a few different options using a tool like taylor. It might not solve the issue of decreased admin effort though... maybe a volunteer system to support certain gateways from one to another might work?
I do have to say that I am glad to see the option of distributed bundle management. I've always had issues managing my own private changes to grammars and such with subversion (I could never get svk working well). Some of the branching and merging capabilities of some of these tools will certainly be welcome.
Brian.
I do have to say that I am glad to see the option of distributed bundle management. I've always had issues managing my own private changes to grammars and such with subversion (I could never get svk working well). Some of the branching and merging capabilities of some of these tools will certainly be welcome.
I know I'd be glad to leave svn behind.
Fred B wrote:
Jacob Rus wrote:
Git has been improving very rapidly though. It is vastly easier for normal (non-power-) users than it was a year ago, and I imagine it will be still better in another year. I don't know if you've tried Git recently; if not you should give it a try. If you stick to the basics, I'd say it's about as easy as SVN. But there's of course a lot of extra power there too, if you want it.
There has been a lot of hype about Git lately and I don't understand why. I'm glad Allan consider Mercurial too, unfortunately some people respond "Ok, let's use Git". ;)
Sorry... my post was certainly not intended as an attack on hg, or bzr, or darcs, or any other system.
But really, the day-to-day usage of git is not IMO a serious barrier to its use by "non-power-users". It's just not that hard IMO to do the basic stuff.
On 8/8/07, Brian Mitchell binary42@gmail.com wrote:
I'm surprised you took that as an attack on mercurial(...)
On 8/11/07, Jacob Rus jacobolus@gmail.com wrote:
Sorry... my post was certainly not intended as an attack on hg, or bzr, or darcs, or any other system.
But really, the day-to-day usage of git is not IMO a serious barrier to its use by "non-power-users". It's just not that hard IMO to do the basic stuff.
I don't think anybody has attacked Mercurial or other systems. It's just that after using a lot of those systems (hg, svk, git, darcs and bzr in a lesser way), Mercurial is my first choice and git the last one. I sincerely wonder why some people seems to favor git recently, because it's a lot less user friendly than other systems, IMHO.
I just wanted to convince everyone to try both (if not more) systems before weighting for one, that's all.
-- FredB
On 8/11/07, Fred B fredb7@gmail.com wrote:
On 8/8/07, Brian Mitchell binary42@gmail.com wrote:
I'm surprised you took that as an attack on mercurial(...)
On 8/11/07, Jacob Rus jacobolus@gmail.com wrote:
Sorry... my post was certainly not intended as an attack on hg, or bzr, or darcs, or any other system.
But really, the day-to-day usage of git is not IMO a serious barrier to its use by "non-power-users". It's just not that hard IMO to do the basic stuff.
I don't think anybody has attacked Mercurial or other systems. It's just that after using a lot of those systems (hg, svk, git, darcs and bzr in a lesser way), Mercurial is my first choice and git the last one. I sincerely wonder why some people seems to favor git recently, because it's a lot less user friendly than other systems, IMHO.
I just wanted to convince everyone to try both (if not more) systems before weighting for one, that's all.
Then please do be more careful. I can easily give examples of where you were quite inaccurate:
- Git is much more difficult to install than Mercurial. Even with
MacPorts: e.g. Git needs new versions of openssh, openssl, curl, rsync, etc. and install more than 135 different commands! This take a lot of time and can be difficult if you have installed some of those outside of MacPorts. On Tiger, the only thing you need before installing Mercurial is upgrading Python to 2.4+. Then it takes 20 sec.
So MacPorts updates some dependencies to ensure one has an up to date environment. The phrase "Git needs new versions" is quite misleading. Git does not require a number of those installations but the package manager you are using has chosen those for you. Over that, both require hefty compilation (Python is not a lightweight package itself either) but it comes down to one easy command in both cases.
- Documentation: Git install a man page for each command (~135) and
have no user manual, not the easiest way to find information when you need it, IMO. Mercurial has 3 man pages and complete doc, check the [official site][1] and the unofficial [hg book][2] (check the comparison between Mercurial and other systems, BTW).
I think you ought to check the git website. There is indeed documentation for each command with good coverage on practically everything git can do but there are also documents on getting started, moving from other systems, setting git up, and even a MANUAL [0]. I find documentation in git a little sub-optimal but having used mercurial in a number of cases I would put the to in similar cases. The reason for so many man pages in git is that it documents and exposes more than just the highest level commands. Git provides a lot of low level stuff that can come in handy when you need it (fortunately rare now that the interface has matured). Fortunately people who want to make use of these commands (maybe for integration into other high-level systems -- textmate?) aren't left in the dark.
- I consider myself a power user and Git is definitely more difficult
to learn and use than Mercurial. The all "index tree" concept adds unneeded complexity, IMHO. (Allan has a hard time making a Git bundle for TM because of that. See the [qit bundle thread][3].) I think that if git is chosen for TM bundles, there will be more git related questions on this list than anything else.
This is one important point but there is more to it than meets the eye.
Indeed, git is not simple to dive into if the frame of reference being used is another version control system. The concepts in git are rather simple and the documentation explains them well. The drawback is that a lot of these concepts are new rather than shared with other systems making it somewhat hard to start off running and expecting to replicate everything done in a different system.
I've found that trying to understand the fundamentals helped me move from the basic commands stage into a much larger range of commands. I can now say that Git's design is rather simple... I just never accepted that answer until I was able to see the complete thing in my mind. Having gone through all of that, I am in the process of helping my coworkers through a migration from Subversion to Git. It will certainly be interesting but so far, they very quickly became capable enough to do everything they did in Subversion.
Measuring learning curves with building a bundle is somewhat unfair as well. Some of the things git does at an integration level are certainly different from those at a basic user level. Again, git has many levels of detail to choose from depending on your needs.
- I read that a Git repository requires frequent manual "repacks" of
its metadata. Mercurial repository needs no maintenance.
Repacking the object database is a simple command and does not need to be done often. The main reason for the command is to optimize the internal representation of objects. Git provides a rather efficient storage system so repacking shouldn't need to be done unless you either need to compress space usage or feel a performance hit after a while. There are possibly ways to automate this but I don't consider it a nuisance since I even bother with this more than once a week if even that. I'm sure people could happily go for months in some cases.
- AFAICT, Mercurial's source code is MUCH more clean and readable (and
I'm not a big fan of Python).
Actually, having been involved in some research into some git pull behavior, I have to say that git is rather nice. I can read C pretty well and don't consider myself allergic to {}'s but pushing syntax aside, there isn't much to complain about.
Some people do get annoyed by the fact that git has a load of shell scripts surrounding the core git command. This is being worked on as a summer of code project IIRC. Though... I guess I don't mind shell scripts either since I come from the unix background in the first place.
I think these sorts of points are far too anecdotal. I consider that there is something valid behind some of them. You will have to try harder to make those points more apparent or at least much more accurate.
Anyway... I hope you see my point. I could lay down my own arguments for Git but I'll say straight out that I'd be completely happy with Mercurial as well. In the long run, anyone interested in version control _should_ learn Git as it really does do some interesting things. Mercurial has some interesting things as well. In fact, even though darcs isn't the most qualified system, it is worth checking out in the name of expanding the mind (I would not recommend the system for textmate's use.. but that is a complicated topic coming from a long time darcs user -- best avoided).
For the people who end up not having their favorite chose, tailor is a wonderful tool (among other options in some cases). I recommend that those who feel their options have been left out regroup and setup something to allow everyone to work in harmony.
Brian.
[0] http://www.kernel.org/pub/software/scm/git/docs/user-manual.html which was linked to from the front page.
- If we make it completely distributed, we still need a central
list of bundles and an easy way to grab them (so need to work out a system for that).
Are you thinking like a web-app? I'd be willing to do some work on this.
-
Alex Ross -
Alexander Ross
-
Allan Odgaard -
Andre Behrens -
Brian Mitchell -
Fred B -
Gerd Knops -
Ivan Pan -
Jacob Rus -
Jeremy Wilkins -
Oliver Hagmann -
Sebastian Gräßl -
Takaaki Kato -
Thomas Aylott -
Thomas Aylott (subtleGradient)
-
Timothy Bates