Re: SCM code changes status
On 2009-02-17, Stefan Bodewig bode...@apache.org wrote: On 2009-02-16, Stefan Bodewig bode...@apache.org wrote: I'll watch the next helios build and then try to merge trunk to live if it looks OK (I removed the directory sync feature by accident, so I better take a closer look). Yesterday things looked fine. I have a merged live branch sitting on my box waiting to be committed as soon as svn is available again. done. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: SCM code changes status
On 16/02/2009, Stefan Bodewig bode...@apache.org wrote: Hi all, apart from some string constants that I want to extract (need to look up Python's idiom for constants) I'm now ready to move ahead - see the differences between svn revisions 741390 and 744799. I'll watch the next helios build and then try to merge trunk to live if it looks OK (I removed the directory sync feature by accident, so I better take a closer look). My tests for svn, CVS and git all work fine locally, I can't test Perforce. If anybody uses Gump with p4 (I doubt so), please give trunk a try and talk about your results. Getting GIT installed is more complicated than I thought since I don't manage to compile it fom sources (not on helios, not on vmgump and not on any of my own machines running Intrepid, Hardy or OpenSUSE), so I'll try a few things with binaries. My changes to the SCM update code should enable new features more easily. In particular I want to make the updaters check whether an existing working copy is in fact a working copy for the configured URL - and blow it away if it isn't. This way if anybody changes the repository for a module we wouldn't need to remove the old working copy manually anymore. I'll probably give this a try before adding support for darcs, hg and bzr. The idea is to look into working-copy/CVS/Root and Repository, working-copy/.svn/entries and working-copy/.git/config respectively - In the case of SVN, perhaps it would be safer to look at the output of svn info rather than relying on the format of the SVN file? Similarly for other SCMs. if anybody knows how to do the same for P4, I'll intergrate that as well. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: SCM code changes status
On 2009-02-16, Stefan Bodewig bode...@apache.org wrote: I'll watch the next helios build and then try to merge trunk to live if it looks OK (I removed the directory sync feature by accident, so I better take a closer look). Yesterday things looked fine. I have a merged live branch sitting on my box waiting to be committed as soon as svn is available again. live and trunk differ in behavior if svn/cvs/p4 fail to update a module. trunk will flag the module as broken and not build any projects contained therein, live will log a warning and assume it is a transient error. I've kept that difference for now, as an added benefit of the refactoring it is now in a single place instead of repeated three times. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: SCM code changes status
On 2009-02-16, sebb seb...@gmail.com wrote: On 16/02/2009, Stefan Bodewig bode...@apache.org wrote: In particular I want to make the updaters check whether an existing working copy is in fact a working copy for the configured URL - and blow it away if it isn't. The idea is to look into working-copy/CVS/Root and Repository, working-copy/.svn/entries and working-copy/.git/config respectively - In the case of SVN, perhaps it would be safer to look at the output of svn info rather than relying on the format of the SVN file? The output of svn info seems to be localized (it speaks German on my machine), so I'm not sure it would provide a more stable API than the file format. In svn info's case it may still work since the URL is on a line of its own. Similarly for other SCMs. Probably a good idea, yes. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
SCM code changes status
Hi all, apart from some string constants that I want to extract (need to look up Python's idiom for constants) I'm now ready to move ahead - see the differences between svn revisions 741390 and 744799. I'll watch the next helios build and then try to merge trunk to live if it looks OK (I removed the directory sync feature by accident, so I better take a closer look). My tests for svn, CVS and git all work fine locally, I can't test Perforce. If anybody uses Gump with p4 (I doubt so), please give trunk a try and talk about your results. Getting GIT installed is more complicated than I thought since I don't manage to compile it fom sources (not on helios, not on vmgump and not on any of my own machines running Intrepid, Hardy or OpenSUSE), so I'll try a few things with binaries. My changes to the SCM update code should enable new features more easily. In particular I want to make the updaters check whether an existing working copy is in fact a working copy for the configured URL - and blow it away if it isn't. This way if anybody changes the repository for a module we wouldn't need to remove the old working copy manually anymore. I'll probably give this a try before adding support for darcs, hg and bzr. The idea is to look into working-copy/CVS/Root and Repository, working-copy/.svn/entries and working-copy/.git/config respectively - if anybody knows how to do the same for P4, I'll intergrate that as well. Stefan - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
