On Tue, Feb 17, 2009 at 10:04:27AM -0500, Joshua Bronson wrote: > I too would be really psyched to switch to distributed version control. > One concern not yet mentioned would be integration in the Trac browser. I > did a quick search and it looks like this is possible > via [1]http://trac-hacks.org/wiki/GitPlugin, though that says it's for > Trac 0.10/0.11 and we're running 0.12dev. Jeff, would you happen to know > anything about this? If it's not too much trouble to get it working with > our Trac installation (and preferably preserve existing [browser:foo] > links, not break post-commit hooks, etc) then let's do it. It looks like a > lot of people are using this in production and it feels fast and > well-integrated: browse around on [2]http://labs.ohloh.net/ohcount/browser > for instance.
I don't know about the status of the GitPlugin. I haven't actually used git for anything yet. I would guess that the 0.11 plugin works (0.12dev is just some seemingly but not really random version of trunk that is effectively in the 0.11 series). Guaranteed it *will* break post-commit hooks, unless someone wants to write a plugin to, um, make this not so (shouldn't be hard, I would hope, though honestly git horrifies me). In any case, I'd be happy to do this if you decide to switch repos. Jeff > On Tue, Feb 17, 2009 at 3:47 AM, Randall Leeds <[3][email protected]> > wrote: > > I absolutely, whole-hearted embrace the idea. > > I haven't really tried Hg, but I'm pretty sold on git having used it for > only a couple weeks. > Just earlier today I was looking at how to mirror melkjug to github so I > could use it myself. Naturally, it doesn't really provide full value > unless we all use it. > > It's easy enough to do as a project. We could pretty easily make > world-readable repositories on melkjug-xen to serve pull requests from. > We could even make an ebuild that pulls from someone's repository, but > it makes most sense to me if it were on more central infrastructure. > > Scott could easily enable something similar on blue, the svn server, by > just installing git or mercurial, etc. > > Of course, since it's distributed, the infrastructure can be fluid, so > we could easily migrate from melkjug-xen later. It's not the best place > to be storing repositories in the long term. Some repository must also > be publicly accessible. > > pip supports git (and mercurial?). > > So, my vote is `emerge git`. Why wait? > -Randall > P.S. Oh, and easy to pull the current svn tree into git. I'm also open > to arguments for whatever other choice of vcs, git's just the only one > I've used. > > On Mon, Feb 16, 2009 at 16:35, Luke Tucker <[4][email protected]> > wrote: > > Hey, > > After hearing rob marianski's talk about distributed version control, > I'm sort of re-psyched about the possibilities of using distributed > version control for melkjug. Also simultaneously, trying to merge > large branches in subversion is giving me the expected headaches... > So I thought maybe I'd get the ball rolling on thinking about whether > it's something we want to do, and if so, when and how. > > I'm not sure right if we need to decide on this organizationally, or > if we can just move on it as a project. No big rush, but I'm for > moving over fairly soon unless there is a larger organizational reason > not to. Rob demonstrated mercurial, but I'm kind of non-bindingly > digging git so far. Anyone have strong opinions about moving/not > moving or about the particular software we use ? > > My next questions would be about how to organize the project packages > and host it if anyone has particular thoughts on that. > > - Luke > > References > > Visible links > 1. http://trac-hacks.org/wiki/GitPlugin > 2. http://labs.ohloh.net/ohcount/browser > 3. mailto:[email protected] > 4. mailto:[email protected] -- Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/02/1234883762785 To unsubscribe send an email with subject "unsubscribe" to [email protected]. Please contact [email protected] for questions.
