I'm using Mercurial, which is a distrusted source control. So you're suggesting using a script, activated via commits to the developer local repository?
Once the developer committed changes to it's repository, the script will build that changes with the latest code, run all the regression tests, unit test, etc...If the test pass fine, then the developer can choose if he wants to push his changes to the main repository? On Friday, August 2, 2013 7:49:16 PM UTC+3, Mark Waite wrote: > > > > On Friday, August 2, 2013 9:17:44 AM UTC-6, Dirk Heinrichs wrote: >> >> Am Freitag, 2. August 2013, 05:14:50 schrieb Mark Waite: >> >> >> > Each developer's private repository could then be added to the job and >> > would be watched for changes, those changes would be merged, and if >> the >> > compile and tests were successful, the merge could be pushed to the >> > integration repository. >> >> There's one drawback with this approach: The developer can never commit >> unfinished code (to save the current state, before leaving for >> vacation,...). >> Not a problem with task branches. >> > > I'm not sure I see the same drawback. In our configuration, Jenkins is > not polling from my working repository, it is polling from a bare > repository which is dedicated solely to me. One bare repository per > developer. Each developer commits unfinished code to their own working > repository, but must not push unfinished code to their bare repository. > > If I have Jenkins polling my working repository, then you're correct, I > can't commit unfinished code to my working repository. I think that would > be very painful. I like a separation between commit and publish. > > Mark Waite > > >> Bye... >> >> Dirk >> >> >> http://www.recommind.com >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
