Carsten Dominik ([EMAIL PROTECTED]) wrote: > On Jul 20, 2007, at 17:28, Adam Spiers wrote: > >This might be a pertinent moment to bring up the topic of revision > >control ... or actually it might be a particularly bad moment, > >considering that the maintainer is about to vanish for 3 weeks! But I > >wanted to propose the idea of adopting a distributed revision control > >system. This would allow any individual coder to (amongst other > >benefits) easily create short-term feature branches or bugfix branches > >off Carsten's releases, share them publically with others for testing, > >and enable very low-cost merging back into the mainstream. To use the > >current situation as one example, this would mean that Carsten can > >relax happily on the beach (or wherever he is ;-) knowing that his > >absence is guaranteed *not* to hold any progress back, even if he > >decided to stay there for several months ;-) > > Now we are talking..... :-)
... and then we stopped - sorry for the long delay, I spent two weeks on a beach myself and it has taken me rather too long to address the resulting backlog :-) > >In case anyone's unfamiliar with the benefits of distributed revision > >control (vs. centralized, e.g. CVS/svn), enjoy this great talk by > >Linus Torvalds at google: > > > > http://www.youtube.com/watch?v=4XpnKHJAok8 > > > >It claims to be about git, but actually it's more about distributed > >revision control systems in general - everything he says applies to > >similar systems such as mercurial. > > Thanks for this enjoyable link - lots of fun to watch Linus like this. Here's an interesting follow-on - a reply from Linus to one of the KDE maintainers who was still not convinced that a decentralized model is always a benefit: http://lwn.net/Articles/246381/ > I'd like to make some comments about the development model or Org-mode > and put it up here for discussion. > > - Org-mode is part of Emacs - this means that I can only accept patches > from people who have signed the appropriate papers with the FSF. You > might have noticed in the past that I usually don't simply apply a > patch. I change it considerably or re-implement the feature, to make > sure that we will not run into copyright issues. If you want to > contribute to org-mode and make life easy for me, write to > [EMAIL PROTECTED] and ask for the paperwork to become a contributor to > org-mode in Emacs, and let me know what you have done so so that I > can start to use your patches directly. I'd be happy to do this to save you work - though that is of course making the big assumption that my patches are usable in their unaltered form ;-) > - The second reason why I often don't apply patches exactly as submitted > is because I see my role in filtering and shaping features so that > they fit exactly into the feel and look of Org-mode as I see it. > I don't want it to loose focus. We are extremely lucky to have such a diligent and effective maintainer! > You might see this as a good thing, but you could also see this > as slowing down development. If that's true, it *is* a good thing because otherwise I could hardly keep up with the rapid pace :-) > - I have never used git or a similar distributed tool - so I would > have to learn how to use them. I can't speak for git, but one of the beautiful things about mercurial is its simplicity; as a result, the learning curve is extremely shallow: http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart There are a load of excellent docs too, e.g. http://www.selenic.com/mercurial/wiki/index.cgi http://hgbook.red-bean.com/hgbook.html There's not much more to it for basic usage. Pushing/pulling can be done with remote repositories, e.g. via ssh or HTTP or even mail. Releases can be symbolically tagged. Merges are made painless. A built-in standalone web server lets anyone publish their repositories instantly via 'hg serve', e.g. http://www.adamspiers.org/hg/ A nice visual tool is bundled to help keep on top of even complicated branching situations: http://lwn.net/Articles/140350/ I would argue that even when still sticking to a centralized development model, it is still worth switching away from CVS or similar: - Bidirectional syncing with CVS and other SCMs well supported - Atomic changesets - Robust repository format - including native cryptographic integrity checks - Renames done right - Symlink support - Branching and merging becomes painless - enables others even if you don't use it personally I could go on but it's time to shut up now I think ;-) _______________________________________________ Emacs-orgmode mailing list Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
