distributed version control?

[Luke Tucker]

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


--
Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/02/1234820143341
To unsubscribe send an email with subject "unsubscribe" to melkjug-dev-***@public.gmane.org Please contact melkjug-dev-manager-ZwoEplunGu1pszqg2B6Wd0B+***@public.gmane.org for questions.

[Randall Leeds]

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.

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
--
http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/02/1234820143341
To unsubscribe send an email with subject "unsubscribe" to

[Joshua Bronson]

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
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 http://labs.ohloh.net/ohcount/browser for instance.

Post by Randall Leeds
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.

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

[Jeff Hammel]

Post by Joshua Bronson
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

Post by Joshua Bronson
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.
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

--
Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/02/1234883762785
To unsubscribe send an email with subject "unsubscribe" to melkjug-dev-***@public.gmane.org Please contact melkjug-dev-manager-ZwoEplunGu1pszqg2B6Wd0B+***@public.gmane.org for questions.

[Randall Leeds]

Post by Jeff Hammel
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 what sense would it break post-commit hooks?
I've never set up a trac instance, but poking around the trac.ini for the
melkjug project I see only the TicketChanger post-commit hook. From what I
gather from http://trac-hacks.org/wiki/TicketChangePlugin I don't see what
this plugin has to do with the chosen SCM backend.

-R

[Joshua Bronson]

Post by Randall Leeds

Post by Jeff Hammel
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 what sense would it break post-commit hooks?
I've never set up a trac instance, but poking around the trac.ini for the
melkjug project I see only the TicketChanger post-commit hook. From what I
gather from http://trac-hacks.org/wiki/TicketChangePlugin I don't see what
this plugin has to do with the chosen SCM backend.
-R

If you look at http://trac.openplans.org/melkjug/admin/repository_hooksyou'll
see some svn-specific stuff there, but assuming git has similar
commit hooks I don't think it would be very hard to change this over. I'm
happy to pair on this with Jeff and/or work on it alone for if and when the
time is right.

One other nit is that when I created our commits mailing
list<http://www.openplans.org/projects/melkjug/lists/melkjug-svn-commits>I
lacked sufficient foresight to give it a general name and address
(fortunately I didn't make that mistake when I made
melkjug-issues-ZwoEplunGu1pszqg2B6Wd0B+***@public.gmane.org for Trac emails). I vote for retiring
melkjug-svn-commits-ZwoEplunGu1pszqg2B6Wd0B+***@public.gmane.org when we switch and setting up a new
melkjug-commits list, but if anyone has a strong opinion otherwise, I defer.

P.S. All the enabled checkboxes on
http://trac.openplans.org/melkjug/admin/repository_hooks are weirdly
unchecked but the hooks are definitely working (at least the last time I
tried "[closes XYZ]" in a commit message Jeff's awesome Repository Change
Listener plugin (see
blue:/usr/local/topp/trac/current/src/RepositoryHookSystem) kicked in and
closed the ticket.

[Jeff Hammel]

Post by Jeff Hammel
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 what sense would it break post-commit hooks?
I've never set up a trac instance, but poking around the trac.ini for
the melkjug project I see only the TicketChanger post-commit hook. From
what I gather from [3]http://trac-hacks.org/wiki/TicketChangePlugin I
don't see what this plugin has to do with the chosen SCM backend.
-R

The issue isn't that TicketChanger is SCM specific (its not, or shouldn't be, in any case, though its only been tested via SVN). The webpage referenced is for a completely unrelated plugin (sorry for the naming confusion!). The home of RepositoryHookSystem is http://trac-hacks.org/wiki/RepositoryHookSystemPlugin. As the diagram shows, the plugin-points (like TicketChanger, http://trac-hacks.org/browser/repositoryhooksystemplugin/0.11/repository_hook_system/ticketchanger.py) should be SCM agnostic. However, they still need something to plug into. For SVN, this is http://trac-hacks.org/browser/repositoryhooksystemplugin/0.11/repository_hook_system/svnhooksystem.py . For Git (and everything else, for that matter), this layer remains unwritten.

Post by Jeff Hammel
If you look at [4]http://trac.openplans.org/melkjug/admin/repository_hooks
you'll see some svn-specific stuff there, but assuming git has similar
commit hooks I don't think it would be very hard to change this over. I'm
happy to pair on this with Jeff and/or work on it alone for if and when
the time is right.

Would be awesome. I have no idea how Git deals with "commit hooks" or really much about how it works, but if its similar to SVN (e.g. files that live on the filesystem) it should be trivial to make a GitHookSystem comparable to the SVNHookSystem in http://trac-hacks.org/browser/repositoryhooksystemplugin/0.11/repository_hook_system/svnhooksystem.py .

Post by Jeff Hammel
One other nit is that when I created our [5]commits mailing list I lacked
sufficient foresight to give it a general name and address (fortunately I
for Trac emails). I vote for
setting up a new melkjug-commits list, but if anyone has a strong opinion
otherwise, I defer.
P.S. All the enabled checkboxes
on [8]http://trac.openplans.org/melkjug/admin/repository_hooks are weirdly
unchecked but the hooks are definitely working (at least the last time I
tried "[closes XYZ]" in a commit message Jeff's awesome Repository Change
Listener plugin (see
blue:/usr/local/topp/trac/current/src/RepositoryHookSystem) kicked in and
closed the ticket.

Yeah, I'm aware of this issue and its noted. The SVNHookSystem (actually, a parent class) parses the commit hook file and looks for it being enabled. In this case, the parse fails, probably because a symlink vs canonical path issue. I've noted the issue (which i thought was noted before, but i guess only in my mind).
http://trac-hacks.org/ticket/4661

The other bug on this page (which i think is fixed in trunk) is that enabled is a checkbox. The apache process does not have permission to write the hook, so trying to save any changes TTW does not work. Worth noting.

Jeff


--
Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/02/1235055266739
To unsubscribe send an email with subject "unsubscribe" to melkjug-dev-***@public.gmane.org Please contact melkjug-dev-manager-ZwoEplunGu1pszqg2B6Wd0B+***@public.gmane.org for questions.

[Randall Leeds]

Post by Jeff Hammel
The issue isn't that TicketChanger is SCM specific (its not, or shouldn't
be, in any case, though its only been tested via SVN). The webpage
referenced is for a completely unrelated plugin (sorry for the naming
confusion!). The home of RepositoryHookSystem is
http://trac-hacks.org/wiki/RepositoryHookSystemPlugin. As the diagram
shows, the plugin-points (like TicketChanger,
http://trac-hacks.org/browser/repositoryhooksystemplugin/0.11/repository_hook_system/ticketchanger.py)
should be SCM agnostic. However, they still need something to plug into.
For SVN, this is
http://trac-hacks.org/browser/repositoryhooksystemplugin/0.11/repository_hook_system/svnhooksystem.py. For Git (and everything else, for that matter), this layer remains
unwritten.

Looks like this might already be done for us.
And of course, the code resides in a git repository :)
http://www.terdmonk.com/2008/12/07/trac-post-commit-hooks-git