You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Stefan Bodewig <bo...@apache.org> on 2009/02/16 06:23:38 UTC
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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: SCM code changes status
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-02-16, sebb <se...@gmail.com> wrote:
> On 16/02/2009, Stefan Bodewig <bo...@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: SCM code changes status
Posted by sebb <se...@gmail.com>.
On 16/02/2009, Stefan Bodewig <bo...@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-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: SCM code changes status
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-02-17, Stefan Bodewig <bo...@apache.org> wrote:
> On 2009-02-16, Stefan Bodewig <bo...@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: SCM code changes status
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-02-16, Stefan Bodewig <bo...@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org