On Fri, Feb 12, 2010 at 6:42 PM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: > On Fri, Feb 12, 2010 at 11:37 AM, Jan Koprowski <jan.koprowski@xxxxxxxxx> wrote: >> Now. My idea. There is some revision tagged as "stable". *Clone* and >> *pull* operations is somehow "overloaded" from server side and always! >> return last revision tagged as stable. After compiling external tool >> just move tag to another revision which pass all tests. Of course >> there is some additional parameter (for example --last or --unstable) >> which can clone fine way of repository. >> >> Two questions. >> 1) Maybe I try to invent the wheel again. Is there any way to take the >> effect without overloading standard git behaviours. >> 2) If not how overload git behaviors on git "server side" repo? > > In general, code that lies to you about what's the most revision is > evil. Sometimes you *do* want to fetch that revision it's lying to > you and saying doesn't exist, precisely because you'd like to help fix > it before integration. > > What you really want is: > > - nobody can push to the "integration branch" except the "integration manager" > > - the "integration manager" should be a computer program, so that you > can have "continuous integration" > > This isn't actually that hard. Give each user their own repository; > no user can write to any other user's repository. (This is the > default setup on github.com, for example.) Alternatively, just tell > people to never, ever push to the master branch by themselves. People > are easily capable of following rules like that unless they're > actively trying to screw you. > > Then set up something like gitbuilder > (http://github.com/apenwarr/gitbuilder) (Full disclosure: I wrote it) > to build *all* the branches from *all* the users. This sounds like it > would create exponential work for the build machine, but it doesn't, > since most users will have mostly the same commits anyway. > > When gitbuilder tags a particular commit as having built and passed > all tests, then it becomes a candidate for merging into the > integration branch. Write a little script that goes through candidate > branches, checks their gitbuilder status, and if they've passed, > pushes them into the integration branch. The push will only succeed > if the integration branch can be fast-forwarded to match the branch > you're trying to push; if you can't, it'll be rejected, which is what > you want, since merging (even conflict-free merging) might break > tests. > > That mechanism works pretty well at my company, with one exception: we > didn't bother with an automatic tool that merges into master. We > prefer to have a release manager do that. > > Have fun, > > Avery > Probably I don't have a problem (or it is a lateness). Because only tagging as stable and making two compile loops: one per management always compiling stable tag and second compiling latest repo... And that is all :D -- ><> Jan Koprowski [696775174] GSM -- 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