Hi!
On Fri, Aug 28, 2009 at 12:32:39PM +0530, Abhijit Bhopatkar wrote:
> I plan to do this on LAN using bonjour service discovery
I wonder why so much emphasis for this? It seems like a nifty
convenience bit, but I don't think making this idea too central is any
good. What if you get a second office at the other end of the world?
What if part of your team is working on a deployment at customer site?
What if part of your team works from home over a VPN? What if your
team is collaborating over the internet on an open project? What if...?
That said, it sounds like a great idea to have let's say a post-commit
hook that will start an upload job:
extbranch="$(whoami)/$(git symbolic-ref HEAD | sed 's#refs/heads/##')"
pushurl="$(melting_pot)"
git push --force "$pushurl" "HEAD:$extbranch" >/dev/null &
(untested, +corner cases). On the server side, cronjob or post-update
hook can do the integration testing. The complete setup should be
a matter of few-minutes hack.
Now, it seems totally irrelevant if melting_pot is
melting_pot() { git config teamgit.meltingpot }
or extra code that tries/caches some local discovery first.
P.S.: It's not clear if you want the information sharing with commit
granularity or less - in that case, things might get rather tricky e.g.
if you add new files and don't git add them until right before you
commit, and the work tree state might be total mess anyway.
P.P.S.: It's not clear if you strive after complete de-centralization of
the service, with no central melting pot. That would seem fancy, but
I think rather useless and hard in practice to arrange your reports
that you want, etc. It's not clear again then if the integration testing
should happen on single machine they all vote on (samba-like), or if
all machines should do integration-testing, and whether of all branches
or only some of them, and how to recognize the interesting branches, and
things are getting very hairy already... Your requirements are too
ambiguous.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html