[GRASS-dev] Launching GRASS 7 development

GRASS GIS GRASS GIS developer
1

While we should concentrate now on getting out 6.3.0 (e.g.,
fixing issues indicated by Helena [1]), it is important
to start planning for a GRASS 7 dev-branch management.

For GRASS 6, we used for quite some time a mixed solution,
with new code stored in the grass6/ repository and linking
old, relevant code from grass[5]/ into it using some link
scripts.

I am not sure if we want the same for grass7/, too.
On the other hand, replicating code is impossible since
it won't be well maintained given our limited resources.

Thoughts also here?

Let's continue to maintain
GRASS 7 ideas collection
http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection

Markus

[1] http://grass.itc.it/pipermail/grass-dev/2007-August/032579.html

2

Markus Neteler wrote:

While we should concentrate now on getting out 6.3.0 (e.g.,
fixing issues indicated by Helena [1]), it is important
to start planning for a GRASS 7 dev-branch management.

For GRASS 6, we used for quite some time a mixed solution,
with new code stored in the grass6/ repository and linking
old, relevant code from grass[5]/ into it using some link
scripts.

I am not sure if we want the same for grass7/, too.
On the other hand, replicating code is impossible since
it won't be well maintained given our limited resources.

Thoughts also here?

I found the "make mix" mechanism to be a nuisance.

Also:

1. I was hoping to bulk-reformat the code with "indent" before we
started doing any actual work on it (so we need to finalise the
formatting conventions).

AFAICT, bulk reformatting is safe. Compiling without -g [1] and with
-DNODEBUG [2] then generating MD5 hashes for all of the .o files
produces the same hashes before and after reformatting.

[1] Debug information includes line numbers.
[2] -DNODEBUG disables the assert() macro, which uses __LINE__

2. Are we going to use CVS or Subversion for 7.x?

--
Glynn Clements <glynn@gclements.plus.com>

3

Markus Neteler schrieb:

While we should concentrate now on getting out 6.3.0 (e.g.,
fixing issues indicated by Helena [1]), it is important
to start planning for a GRASS 7 dev-branch management.

For GRASS 6, we used for quite some time a mixed solution,
with new code stored in the grass6/ repository and linking
old, relevant code from grass[5]/ into it using some link
scripts.

I am not sure if we want the same for grass7/, too.
On the other hand, replicating code is impossible since
it won't be well maintained given our limited resources.

Thoughts also here?

Let's continue to maintain
GRASS 7 ideas collection
http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection

Markus

[1] http://grass.itc.it/pipermail/grass-dev/2007-August/032579.html

I'm only a (non frequent) user of grass. But wouldn't it be nice to have grass7 with its own shell, to get rid of all these bash dependencies which make many modules hardly portable (I would prefer a python like shell).
It is just a suggestion as I'm not able to contribute code.

regards
wolfgang

4

On Sat, Aug 11, 2007 at 10:18:47PM +0100, Glynn Clements wrote:

Markus Neteler wrote:
> While we should concentrate now on getting out 6.3.0 (e.g.,
> fixing issues indicated by Helena [1]), it is important
> to start planning for a GRASS 7 dev-branch management.
>
> For GRASS 6, we used for quite some time a mixed solution,
> with new code stored in the grass6/ repository and linking
> old, relevant code from grass[5]/ into it using some link
> scripts.
>
> I am not sure if we want the same for grass7/, too.
> On the other hand, replicating code is impossible since
> it won't be well maintained given our limited resources.
>
> Thoughts also here?

I found the "make mix" mechanism to be a nuisance.

Me, too.

Also:

1. I was hoping to bulk-reformat the code with "indent" before we
started doing any actual work on it (so we need to finalise the
formatting conventions).

AFAICT, bulk reformatting is safe. Compiling without -g [1] and with
-DNODEBUG [2] then generating MD5 hashes for all of the .o files
produces the same hashes before and after reformatting.

[1] Debug information includes line numbers.
[2] -DNODEBUG disables the assert() macro, which uses __LINE__

This sounds very good.

2. Are we going to use CVS or Subversion for 7.x?

My suggestion is to start new repository from scratch in SVN
using the *migrated* CVS repos to maintain history. This is essential,
also for copyright issues and other reasons. Moving files around in SVN
is very easy (while it is not in CVS). The hassle of double maintenance
(backporting) would remain of course.

Since the CVS admins signalled to have no time for a migration,
we can temporarily start on "my" own SVN server or ask for an
OSGeo SVN server repository.

Still we have to figure out the flags of the cvs2svn conversion script.

Markus

5

On Aug 12, 2007, at 3:40 PM, Markus Neteler wrote:

On Sat, Aug 11, 2007 at 10:18:47PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

While we should concentrate now on getting out 6.3.0 (e.g.,
fixing issues indicated by Helena [1]), it is important
to start planning for a GRASS 7 dev-branch management.

For GRASS 6, we used for quite some time a mixed solution,
with new code stored in the grass6/ repository and linking
old, relevant code from grass[5]/ into it using some link
scripts.

I am not sure if we want the same for grass7/, too.
On the other hand, replicating code is impossible since
it won't be well maintained given our limited resources.

Thoughts also here?

I found the "make mix" mechanism to be a nuisance.

Me, too.

Also:

1. I was hoping to bulk-reformat the code with "indent" before we
started doing any actual work on it (so we need to finalise the
formatting conventions).

AFAICT, bulk reformatting is safe. Compiling without -g [1] and with
-DNODEBUG [2] then generating MD5 hashes for all of the .o files
produces the same hashes before and after reformatting.

[1] Debug information includes line numbers.
[2] -DNODEBUG disables the assert() macro, which uses __LINE__

This sounds very good.

2. Are we going to use CVS or Subversion for 7.x?

My suggestion is to start new repository from scratch in SVN
using the *migrated* CVS repos to maintain history. This is essential,
also for copyright issues and other reasons. Moving files around in SVN
is very easy (while it is not in CVS). The hassle of double maintenance
(backporting) would remain of course.

Since the CVS admins signalled to have no time for a migration,
we can temporarily start on "my" own SVN server or ask for an
OSGeo SVN server repository.

Markus - I suggest to avoid temporary solutions because they tend to stick
around for years. Let us try the OSGeo SVN server if you think that it will work
- that may help to test and build a strong OSGeo infrastructure.

Helena

Still we have to figure out the flags of the cvs2svn conversion script.

Markus

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

6

WolfgangZ wrote:

> While we should concentrate now on getting out 6.3.0 (e.g.,
> fixing issues indicated by Helena [1]), it is important
> to start planning for a GRASS 7 dev-branch management.
>
> For GRASS 6, we used for quite some time a mixed solution,
> with new code stored in the grass6/ repository and linking
> old, relevant code from grass[5]/ into it using some link
> scripts.
>
> I am not sure if we want the same for grass7/, too.
> On the other hand, replicating code is impossible since
> it won't be well maintained given our limited resources.
>
> Thoughts also here?
>
> Let's continue to maintain
> GRASS 7 ideas collection
> http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection
>
> Markus
>
> [1] http://grass.itc.it/pipermail/grass-dev/2007-August/032579.html

I'm only a (non frequent) user of grass. But wouldn't it be nice to have
  grass7 with its own shell, to get rid of all these bash dependencies
which make many modules hardly portable (I would prefer a python like
shell).

The choice of shell must be up to the user. bash is a perfectly good
interactive shell; it just sucks (badly) as a programming language,
and will probably never be satisfactory on Windows.

For 7.x, my choice would be to require the use of Python for any
scripts which are part of GRASS, with the possible exception of any
critical scripts (e.g. Init.sh), where it may be worthwhile
maintaining at least minimal /bin/sh and cmd.exe versions, so that
users who (for whatever reason) do not have Python can still use most
of GRASS.

--
Glynn Clements <glynn@gclements.plus.com>

7

Markus Neteler wrote:

Still we have to figure out the flags of the cvs2svn conversion
script.

one problem I have seen before in CVS->SVN is binaries (ie image.gif)
get corrupted if not -kb flagged in CVS. IIRC Glynn bulk corrected this
some months ago, so hopefully that part will be smooth.

I agree with Helena about avoiding double-handling. It's better to do
the migration once, correctly.

Is there anything the community can do to help getting the freegis.org
server ready for SVN? CVS access & uptime from intevation.de has been
excellent IMO.

Hamish

8

Am Dienstag, 14. August 2007 03:02 schrieb Hamish:

Markus Neteler wrote:
> Still we have to figure out the flags of the cvs2svn conversion
> script.

one problem I have seen before in CVS->SVN is binaries (ie image.gif)
get corrupted if not -kb flagged in CVS. IIRC Glynn bulk corrected this
some months ago, so hopefully that part will be smooth.

I agree with Helena about avoiding double-handling. It's better to do
the migration once, correctly.

Is there anything the community can do to help getting the freegis.org
server ready for SVN? CVS access & uptime from intevation.de has been
excellent IMO.

Thanks. Actually our infrastructiure has SVN ready to start over. See on
wald[1], there is already a GRASS-project where the trackers are running.

Is that what you expect?!

Best regards

  Stephan

[1] http://wald.intevation.org
--
Stephan Holl <stephan.holl@intevation.de>, http://intevation.de/~stephan
Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabrück - HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

9

Stephan Holl-3 wrote:

Am Dienstag, 14. August 2007 03:02 schrieb Hamish:

Markus Neteler wrote:
> Still we have to figure out the flags of the cvs2svn conversion
> script.

one problem I have seen before in CVS->SVN is binaries (ie image.gif)
get corrupted if not -kb flagged in CVS. IIRC Glynn bulk corrected this
some months ago, so hopefully that part will be smooth.

I agree with Helena about avoiding double-handling. It's better to do
the migration once, correctly.

Is there anything the community can do to help getting the freegis.org
server ready for SVN? CVS access & uptime from intevation.de has been
excellent IMO.

Thanks. Actually our infrastructiure has SVN ready to start over. See on
wald[1], there is already a GRASS-project where the trackers are running.

Is that what you expect?!

Best regards

  Stephan

[1] http://wald.intevation.org

I don't know from the indicated wald page. What we need is that the CVS2SVN
migration is launched on the CVS server and stuff migrated to SVN including
code
history. It was communicated by Bernhard that there is no time for that in
the near
future.

But we should no longer wait, otherwise some developers may go away.
Since OSGeo is offering SVN infrastructure to the OSGeo projects, this could
be an alternative then.

Markus
--
View this message in context: http://www.nabble.com/Launching-GRASS-7-development-tf4254095.html#a12139583
Sent from the Grass - Dev mailing list archive at Nabble.com.

10

On Dienstag, 14. August 2007, Markus Neteler wrote:

Stephan Holl-3 wrote:
> Am Dienstag, 14. August 2007 03:02 schrieb Hamish:
>> Markus Neteler wrote:
>> > Still we have to figure out the flags of the cvs2svn conversion
>> > script.
>>
>> one problem I have seen before in CVS->SVN is binaries (ie image.gif)
>> get corrupted if not -kb flagged in CVS. IIRC Glynn bulk corrected this
>> some months ago, so hopefully that part will be smooth.
>>
>>
>> I agree with Helena about avoiding double-handling. It's better to do
>> the migration once, correctly.
>>
>> Is there anything the community can do to help getting the freegis.org
>> server ready for SVN? CVS access & uptime from intevation.de has been
>> excellent IMO.
>
> Thanks. Actually our infrastructiure has SVN ready to start over. See on
> wald[1], there is already a GRASS-project where the trackers are running.
>
> Is that what you expect?!
>
> Best regards
>
> Stephan
>
> [1] http://wald.intevation.org
>

I don't know from the indicated wald page. What we need is that the CVS2SVN
migration is launched on the CVS server and stuff migrated to SVN including
code
history. It was communicated by Bernhard that there is no time for that in
the near
future.

how long ago was that? :wink:

But we should no longer wait, otherwise some developers may go away.
Since OSGeo is offering SVN infrastructure to the OSGeo projects, this could
be an alternative then.

once there is a SVN repository, it could easily be integrated into Wald or any
other SVN infrastructure.

This first step (cvs2svn) needs to be done anyway and this is the one that
consumes time.

It is good that the binary problems are fixed meanwhile, I didn't notice this
change.

IIUC, we just need to define a time for commit stop and then take a snapshot of the
CVS repository, apply cvs2svn to it (find out about apropriate parameters, I have
done this task a couple of times), check the result and put it into the development
platforms' SVN place.

Best

  Jan

--
Dr. Jan-Oliver Wagner Intevation GmbH, Osnabrück
Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

11

Jan-Oliver Wagner wrote on 08/22/2007 02:25 PM:

On Dienstag, 14. August 2007, Markus Neteler wrote:
  

Stephan Holl-3 wrote:
    

Am Dienstag, 14. August 2007 03:02 schrieb Hamish:
      

Markus Neteler wrote:
        

Still we have to figure out the flags of the cvs2svn conversion
script.
          

one problem I have seen before in CVS->SVN is binaries (ie image.gif)
get corrupted if not -kb flagged in CVS. IIRC Glynn bulk corrected this
some months ago, so hopefully that part will be smooth.

I agree with Helena about avoiding double-handling. It's better to do
the migration once, correctly.

Is there anything the community can do to help getting the freegis.org
server ready for SVN? CVS access & uptime from intevation.de has been
excellent IMO.
        

Thanks. Actually our infrastructiure has SVN ready to start over. See on
wald[1], there is already a GRASS-project where the trackers are running.

Is that what you expect?!

Best regards

  Stephan

[1] http://wald.intevation.org

I don't know from the indicated wald page. What we need is that the CVS2SVN
migration is launched on the CVS server and stuff migrated to SVN including
code
history. It was communicated by Bernhard that there is no time for that in
the near
future.
    
how long ago was that? :wink:
  

It was 18 Jul 2007...

But we should no longer wait, otherwise some developers may go away.
Since OSGeo is offering SVN infrastructure to the OSGeo projects, this could
be an alternative then.
    
once there is a SVN repository, it could easily be integrated into Wald or any
other SVN infrastructure.

This first step (cvs2svn) needs to be done anyway and this is the one that
consumes time.
  

Yes, sure. The problem is: how to get the script settings right.

It is good that the binary problems are fixed meanwhile, I didn't notice this
change.

IIUC, we just need to define a time for commit stop and then take a snapshot of the
CVS repository, apply cvs2svn to it (find out about apropriate parameters, I have
done this task a couple of times), check the result and put it into the development
platforms' SVN place.
  

I suggest that we don't stop CVS unless the actual migration is done.
Since CVS is available via rsync, we will continue to build a SVN
repository on one
of our servers to figure out the cvs2svn parameters. Once it is really
working, we
can do the migration. I understood that Intevation has already migrated
CVS repositories,
so it would be helpful to learn from your experience.

Markus

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

12

On Wednesday 22 August 2007 18:30, Markus Neteler wrote:

Jan-Oliver Wagner wrote on 08/22/2007 02:25 PM:
> On Dienstag, 14. August 2007, Markus Neteler wrote:
>> But we should no longer wait, otherwise some developers may go away.
>> Since OSGeo is offering SVN infrastructure to the OSGeo projects, this
>> could be an alternative then.
>
> once there is a SVN repository, it could easily be integrated into Wald
> or any other SVN infrastructure.
>
> This first step (cvs2svn) needs to be done anyway and this is the one
> that consumes time.

Yes, sure. The problem is: how to get the script settings right.

I tried this command
cvs2svn --no-default-eol --fs-type=fsfs -s grass-svn grassrepository
and got this errors:

...
Pass 1 complete.

Error summary:
ERROR: A CVS repository cannot contain both
grassrepository/grass6/display/d.erase/main.c,v and
grassrepository/grass6/display/d.erase/Attic/main.c,v
ERROR: A CVS repository cannot contain both
grassrepository/grass6/general/g.mapsets/main_inter.c,v and
grassrepository/grass6/general/g.mapsets/Attic/main_inter.c,v
ERROR: A CVS repository cannot contain both
grassrepository/grass6/include/gproj_api.h,v and
grassrepository/grass6/include/Attic/gproj_api.h,v
ERROR: A CVS repository cannot contain both
grassrepository/grass6/visualization/nviz/src/getCat.c,v and
grassrepository/grass6/visualization/nviz/src/Attic/getCat.c,v
Exited due to fatal error(s).

> It is good that the binary problems are fixed meanwhile, I didn't notice
> this change.
>
> IIUC, we just need to define a time for commit stop and then take a
> snapshot of the CVS repository, apply cvs2svn to it (find out about
> apropriate parameters, I have done this task a couple of times), check
> the result and put it into the development platforms' SVN place.

I suggest that we don't stop CVS unless the actual migration is done.
Since CVS is available via rsync, we will continue to build a SVN
repository on one
of our servers to figure out the cvs2svn parameters. Once it is really
working, we
can do the migration.

sure.

I understood that Intevation has already migrated
CVS repositories,
so it would be helpful to learn from your experience.

I'll try my very best. However, GRASS is bigger than anything
I migrated before.

--
Dr. Jan-Oliver Wagner Intevation GmbH
Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner