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
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
