Menu
▾
▴
treebase-devel
|
From: Rutger V. <rut...@gm...> - 2011-04-19 11:32:58
|
I don't know who hudson is and since when we have him, but he seems to have done a continuous build that failed when I made my first commit. Now he says everything is back to normal - though I'm still getting a 503. ---------- Forwarded message ---------- From: IT Admin <it...@ne...> Date: Tue, Apr 19, 2011 at 12:01 PM Subject: Hudson build is back to normal : Treebase-dev #92 To: vga...@ne..., rut...@gm... See <http://hudson.nescent.org/job/Treebase-dev/92/changes> -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading RG6 6BX United Kingdom Tel: +44 (0) 118 378 7535 http://www.nexml.org http://rutgervos.blogspot.com |
|
From: Hilmar L. <hl...@ne...> - 2011-04-19 13:30:32
|
Hudson will rebuild and redeploy TreeBASE whenever you commit. It's a continuous integration tool: http://hudson-ci.org/ -hilmar On Apr 19, 2011, at 4:32 AM, Rutger Vos wrote: > I don't know who hudson is and since when we have him, but he seems to > have done a continuous build that failed when I made my first commit. > Now he says everything is back to normal - though I'm still getting a > 503. > > > ---------- Forwarded message ---------- > From: IT Admin <it...@ne...> > Date: Tue, Apr 19, 2011 at 12:01 PM > Subject: Hudson build is back to normal : Treebase-dev #92 > To: vga...@ne..., rut...@gm... > > > See <http://hudson.nescent.org/job/Treebase-dev/92/changes> > > > > > > -- > Dr. Rutger A. Vos > School of Biological Sciences > Philip Lyle Building, Level 4 > University of Reading > Reading > RG6 6BX > United Kingdom > Tel: +44 (0) 118 378 7535 > http://www.nexml.org > http://rutgervos.blogspot.com > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and > improve > application availability and disaster protection. Learn more about > boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Rutger V. <rut...@gm...> - 2011-04-19 13:34:44
|
Not sure if I was supposed to know that - so any commit goes live on the production server immediately? That means I'm going to have to change my commit behavior, I tend to commit files individually so that I can give more specific messages to explain the changes in each of them. Bulk commits will have to have more generic explanations, I guess. Do I have a login on hudson? Rutger On Tue, Apr 19, 2011 at 2:30 PM, Hilmar Lapp <hl...@ne...> wrote: > Hudson will rebuild and redeploy TreeBASE whenever you commit. It's a > continuous integration tool: http://hudson-ci.org/ > > -hilmar > > On Apr 19, 2011, at 4:32 AM, Rutger Vos wrote: > >> I don't know who hudson is and since when we have him, but he seems to >> have done a continuous build that failed when I made my first commit. >> Now he says everything is back to normal - though I'm still getting a >> 503. >> >> >> ---------- Forwarded message ---------- >> From: IT Admin <it...@ne...> >> Date: Tue, Apr 19, 2011 at 12:01 PM >> Subject: Hudson build is back to normal : Treebase-dev #92 >> To: vga...@ne..., rut...@gm... >> >> >> See <http://hudson.nescent.org/job/Treebase-dev/92/changes> >> >> >> >> >> >> -- >> Dr. Rutger A. Vos >> School of Biological Sciences >> Philip Lyle Building, Level 4 >> University of Reading >> Reading >> RG6 6BX >> United Kingdom >> Tel: +44 (0) 118 378 7535 >> http://www.nexml.org >> http://rutgervos.blogspot.com >> >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about >> boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> _______________________________________________ >> Treebase-devel mailing list >> Tre...@li... >> https://lists.sourceforge.net/lists/listinfo/treebase-devel > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > > -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading RG6 6BX United Kingdom Tel: +44 (0) 118 378 7535 http://www.nexml.org http://rutgervos.blogspot.com |
|
From: Vladimir G. <vla...@du...> - 2011-04-19 13:56:48
|
On Apr 19, 2011, at 9:34 AM, Rutger Vos wrote: > Not sure if I was supposed to know that - so any commit goes live on > the production server immediately? That means I'm going to have to > change my commit behavior, I tend to commit files individually so that > I can give more specific messages to explain the changes in each of > them. Bulk commits will have to have more generic explanations, I > guess. Only treebase-dev is built and deployed automatically by hudson. Production is also deployed through hudson, but that is triggered manually, as needed. It's indeed a good idea to only commit code that is believed to be buildable and runnable. -V |
|
From: Rutger V. <R....@re...> - 2011-04-19 14:01:12
|
> Only treebase-dev is built and deployed automatically by hudson. > Production is also deployed through hudson, but that is triggered > manually, as needed. > It's indeed a good idea to only commit code that is believed to be > buildable and runnable. > -V Well, I wouldn't walk away in the middle of committing a series of files - just didn't realize they had to be atomic. Now I know. -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading, RG6 6BX, United Kingdom Tel: +44 (0) 118 378 7535 http://rutgervos.blogspot.com |
|
From: Hilmar L. <hl...@ne...> - 2011-04-19 14:03:34
|
On Apr 19, 2011, at 6:34 AM, Rutger Vos wrote: > Not sure if I was supposed to know that - so any commit goes live on > the production server immediately? On dev only, not production. I can dig through the mailing list archives, but if my recollection is correct, this was discussed here and agreed to by Bill. > That means I'm going to have to change my commit behavior, I tend to > commit files individually so that I can give more specific messages > to explain the changes in each of them. I've shared that concern. I still think we shouldn't change commit behavior; just be prepared that sometimes the Hudson builds will fail while you're in the midst of something. In part this is also a result of our not better exploiting the capabilities of version control. It's arguably not the best idea to do development of features or changes that amount to more than "atomic" bug fixes on the main trunk. If we were on git, this would probably mostly solve itself, as branching and switching between branches is just so easy that there are few excuses not to do it. Merges back to master would then contain all the changes that as a whole would not break the build. But it's not that svn doesn't support branching and merging. > Do I have a login on hudson? I don't know - ask for one if you need one (do you?). -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Rutger V. <rut...@gm...> - 2011-04-19 14:10:47
|
> On dev only, not production. I can dig through the mailing list archives, > but if my recollection is correct, this was discussed here and agreed to by > Bill. Don't worry, I'll take your word for it. >> That means I'm going to have to change my commit behavior, I tend to >> commit files individually so that I can give more specific messages to >> explain the changes in each of them. > > I've shared that concern. I still think we shouldn't change commit behavior; > just be prepared that sometimes the Hudson builds will fail while you're in > the midst of something. Ah, ok, I guess I'll learn to live with the occasional complaint from Hudson. I don't commit code that, as a whole, is broken (...well...), but I do push the commits out in a series. > In part this is also a result of our not better exploiting the capabilities > of version control. It's arguably not the best idea to do development of > features or changes that amount to more than "atomic" bug fixes on the main > trunk. > > If we were on git, this would probably mostly solve itself, as branching and > switching between branches is just so easy that there are few excuses not to > do it. Merges back to master would then contain all the changes that as a > whole would not break the build. But it's not that svn doesn't support > branching and merging. Yeah, it does support it, but just in a goofy way. The extra folders it creates aren't particularly pretty. I'm really starting to like git - perhaps at some point we might move the code base to github? Bit of a pain because we do use some of the supporting infrastructure that sourceforge provides: the wiki, the mailing list(s), the bug tracker. Mmmmm. >> Do I have a login on hudson? > > I don't know - ask for one if you need one (do you?). I don't know, what would it tell me beyond a stack trace when the dev won't build at a given point in time? I don't really need to see that, probably. Rutger -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading RG6 6BX United Kingdom Tel: +44 (0) 118 378 7535 http://www.nexml.org http://rutgervos.blogspot.com |
|
From: Hilmar L. <hl...@ne...> - 2011-04-19 14:20:47
|
On Apr 19, 2011, at 7:10 AM, Rutger Vos wrote: > perhaps at some point we might move the code base to github? Bit of > a pain because we do use some of the supporting infrastructure that > sourceforge provides: the wiki, the mailing list(s), the bug tracker. Note that moving to git need not mean moving to Github - Sf.net supports git (albeit as a current limitation a project can only have one git repository - which, though, wouldn't be different from having one svn repository as we do now). Also, having a repository on Github does not preclude having one on Sf.net, too (git is distributed version control, and pushing to multiple remotes is easy). And finally, having the repo on Github does not preclude having the remaining infrastructure on Sf.net. So, in summary, there are lots of possibilities so that the question of where other project resources are hosted need not dictate the choice of version control system. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X