[GRASS5] Let's release 5.4 asap

Hi developers,

I still didn't read all the messages from the last weeks
but would like to suggestion to get out 5.4 as soon as possible
(means within days/weeks time frame). There is not much point
in not releasing it for two main reasons:

- 5.0 is now really outdated

- In the community 5.0 is considered to be stable and so it is
   heavily used (we saw that in Bangkok). People complained about
  problems which we already solved month/years ago. On the other
  hand it is pretty difficult to convince them to change to
  5.3 as they say "why is it indicated as development version then?".
  Software can always be better. Waiting with a 5.4 release doesn't
  make sense as open things are not going to be solved in the
  near future (shared libs on Mac etc). So, please, let's get 5.4
  out and "downgrade" 5.0 in it's importance.

  To have 3 versions on the web site is considered to be very
  confusing (I heard that many times the last weeks).

Putting much efforts into 5.3 (tcltkgrass etc) might not be worth
the time spent. We have 5.7 and we should concentrate on this version.

So, what's holding a 5.4.0 release? Any important problems which
will be fixed *soon*? Let me cite these mails:

http://grass.itc.it/pipermail/grass5/2004-July/014954.html
http://grass.itc.it/pipermail/grass5/2004-July/014955.html
"my plan is that when 5.3 can be compiled with shared libraries on all
  supported platforms, we should make this the default and release it as
  5.3.1"

We are probably years away from that due to personal time constraints.
Instead of holding the 5.4 release for further month/years, we should
get it out. Once the shared lib problems are solved we can publish the
next subversion.

Markus

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Agreed fully (for what it's worth).
Rest assured that from a user's point of view the problems cited by Markus are
very real.
So, good luck for the new 5.4!

At 18:44, mercoledì 29 settembre 2004, Markus Neteler has probably written:

We are probably years away from that due to personal time constraints.
Instead of holding the 5.4 release for further month/years, we should
get it out. Once the shared lib problems are solved we can publish the
next subversion.

Markus

- --
Paolo Cavallini
cavallini@faunalia.it www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953
GPG key @: hkp://wwwkeys.pgp.net http://www.pgp.net/wwwkeys.html
https://www.biglumber.com
Only free software: www.gnu.org / www.linux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBWvPW/NedwLUzIr4RAhf2AJ9uGOVP8krVqC+HXHSYy6uQ77S0tQCeOqj8
Nn+yyYzuHfDXu8C8Ida64QM=
=SAK0
-----END PGP SIGNATURE-----

Putting much efforts into 5.3 (tcltkgrass etc) might not be worth
the time spent. We have 5.7 and we should concentrate on this version.

So, what's holding a 5.4.0 release? Any important problems which
will be fixed *soon*?

Hi, re a cosmetic problem with tcltkgrass

fixing the tcl {quoting} of multiply defined option answers a while back
makes the command preview at the bottom of the tcl menu show options
quoted with {}s instead of ''s for a term. This is done for 5.7, but I
couldn't figure it out for 5.3 (realtime updating) and haven't had the
time to spend on it. I don't think it is very hard but I don't
understand the tcl stuff enough to quickly solve it.

I think cutting and pasting that command to a text file is very
important for learning the different commands & developing scripts, so
it would be really nice if that were fixed.

http://freegis.org/cgi-bin/viewcvs.cgi/grass/src/tcltkgrass/main/gui.tcl.diff?r1=1.20&r2=1.21

also there were some problems reported which should be addressed:

http://article.gmane.org/gmane.comp.gis.grass.devel/4588

minor but IMO important problems, and I'm really busy right now....

thanks,
Hamish

Hello Markus

On Wed, 29 Sep 2004, Markus Neteler wrote:

Hi developers,

I still didn't read all the messages from the last weeks
but would like to suggestion to get out 5.4 as soon as possible
(means within days/weeks time frame). There is not much point
in not releasing it for two main reasons:

- 5.0 is now really outdated

- In the community 5.0 is considered to be stable and so it is
  heavily used (we saw that in Bangkok). People complained about
problems which we already solved month/years ago. On the other
hand it is pretty difficult to convince them to change to
5.3 as they say "why is it indicated as development version then?".

But for a long time now it has said on the website 5.3 is 'testing' and 5.0 is 'stable but outdated' which I feel is a very good discouragement from using it. Straight away we could delete 5.0 from the list on the front page leaving only 5.3 and 5.7 I think.

Software can always be better. Waiting with a 5.4 release doesn't
make sense as open things are not going to be solved in the
near future (shared libs on Mac etc). So, please, let's get 5.4
out and "downgrade" 5.0 in it's importance.

The thing is that once 5.4 is released we are going to stop CVS access to the grass repository and only work on 5.7. But considering people are going to be going on using 5.3 for many many years we still need to fix everything that was added since 5.0 but is not finished yet.

To have 3 versions on the web site is considered to be very
confusing (I heard that many times the last weeks).

Well we can take 5.0 off right now I think.

Putting much efforts into 5.3 (tcltkgrass etc) might not be worth the time spent.

I think it will greatly reduce the volume of annoying complaints from people in the future if we make sure what's there now works, before 5.4.

We have 5.7 and we should concentrate on this version.
So, what's holding a 5.4.0 release? Any important problems which
will be fixed *soon*? Let me cite these mails:

http://grass.itc.it/pipermail/grass5/2004-July/014954.html
http://grass.itc.it/pipermail/grass5/2004-July/014955.html
"my plan is that when 5.3 can be compiled with shared libraries on all
supported platforms, we should make this the default and release it as
5.3.1"

We are probably years away from that due to personal time constraints.

Maybe not as far as it seems. I said to Lorenzo that I may have access to a Mac at my new job now, where I could test out the shared libraries problems on OS X. I think Cygwin is already OK. I just haven't asked the person with the Mac for access yet.

Instead of holding the 5.4 release for further month/years, we should
get it out. Once the shared lib problems are solved we can publish the
next subversion.

I'm not sure about that---I thought there would be virtually no more changes at all to 5.4 after we release 5.4.0. That understanding is what would make me hesitant to agree to a quick release. If that was changed, things would be different.

Paul

Hello Paul,

On Thu, Sep 30, 2004 at 03:32:15PM +0100, Paul Kelly wrote:

Hello Markus

On Wed, 29 Sep 2004, Markus Neteler wrote:

>Hi developers,
>
>I still didn't read all the messages from the last weeks
>but would like to suggestion to get out 5.4 as soon as possible
>(means within days/weeks time frame). There is not much point
>in not releasing it for two main reasons:
>
>- 5.0 is now really outdated
>
>- In the community 5.0 is considered to be stable and so it is
> heavily used (we saw that in Bangkok). People complained about
> problems which we already solved month/years ago. On the other
> hand it is pretty difficult to convince them to change to
> 5.3 as they say "why is it indicated as development version then?".

But for a long time now it has said on the website 5.3 is 'testing' and
5.0 is 'stable but outdated' which I feel is a very good discouragement
from using it.

I was hoping that as well, but it's unfortunately not true.
Many GRASS users seem to be very conservative concerning version
numbers. I asked several people in Bangkok why they used 5.0.x
and then presented long lists of problems in their conclusions
(most of them are already solved in 5.3/5.7). They answered that
the web pages indicate 5.3 only as testing but 5.0 is indicated
as stable.

Straight away we could delete 5.0 from the list on the
front page leaving only 5.3 and 5.7 I think.

I'll do that if there aren't objections.

> Software can always be better. Waiting with a 5.4 release doesn't
> make sense as open things are not going to be solved in the
> near future (shared libs on Mac etc). So, please, let's get 5.4
> out and "downgrade" 5.0 in it's importance.

The thing is that once 5.4 is released we are going to stop CVS access to
the grass repository and only work on 5.7. But considering people are
going to be going on using 5.3 for many many years we still need to fix
everything that was added since 5.0 but is not finished yet.

Oh. This will take another few years :slight_smile:

> To have 3 versions on the web site is considered to be very
> confusing (I heard that many times the last weeks).

Well we can take 5.0 off right now I think.

It should also disappear from the download page then.

>Putting much efforts into 5.3 (tcltkgrass etc) might not be worth the
>time spent.

I think it will greatly reduce the volume of annoying complaints from
people in the future if we make sure what's there now works, before 5.4.

Mmh. So we better do not look at the bugtracker.
IMHO we need a pragmatic solution. 5.3 is quite good now.
And 5.4 can stay open for bugfixes of course.

At least I would like to get rid of the complicated merge
procedure for 5.7 which is hard to explain to non-experts and
also makes RPM packaging difficult.
For that 5.3 has to be sort of frozen.

>We have 5.7 and we should concentrate on this version.
>So, what's holding a 5.4.0 release? Any important problems which
>will be fixed *soon*? Let me cite these mails:
>
>http://grass.itc.it/pipermail/grass5/2004-July/014954.html
>http://grass.itc.it/pipermail/grass5/2004-July/014955.html
>"my plan is that when 5.3 can be compiled with shared libraries on all
> supported platforms, we should make this the default and release it as
> 5.3.1"
>
>We are probably years away from that due to personal time constraints.

Maybe not as far as it seems. I said to Lorenzo that I may have access to
a Mac at my new job now, where I could test out the shared libraries
problems on OS X. I think Cygwin is already OK. I just haven't asked the
person with the Mac for access yet.

Is this the limiting factor? Other *important* outstanding problems?

>Instead of holding the 5.4 release for further month/years, we should
>get it out. Once the shared lib problems are solved we can publish the
>next subversion.

I'm not sure about that---I thought there would be virtually no more
changes at all to 5.4 after we release 5.4.0. That understanding is what
would make me hesitant to agree to a quick release. If that was changed,
things would be different.

Again, we need a new version soon which can be called "stable" according
to the version number. After a 5.4 release bugfixing is obviously possible.
But why adding new features to 5.4 if 5.7 is already there? With 10 more
developers it might be feasible to maintain two versions but currently...

Markus

Hello Markus,

I agree with your assessment that a new stable release is needed
as not much bugfixing is going on for 5.0.x and having three
versions out is not the best solution.

Not having tried 5.3.x much, I cannot evalutate its stability.
Assuming that user feedback is fine we should make it 5.4.0
and then aim for bug-fix releases.

On Thu, Sep 30, 2004 at 04:56:34PM +0200, Markus Neteler wrote:

On Thu, Sep 30, 2004 at 03:32:15PM +0100, Paul Kelly wrote:
> On Wed, 29 Sep 2004, Markus Neteler wrote:

Many GRASS users seem to be very conservative concerning version
numbers. I asked several people in Bangkok why they used 5.0.x
and then presented long lists of problems in their conclusions
(most of them are already solved in 5.3/5.7). They answered that
the web pages indicate 5.3 only as testing but 5.0 is indicated
as stable.

> Straight away we could delete 5.0 from the list on the
> front page leaving only 5.3 and 5.7 I think.

I'll do that if there aren't objections.

No, please do not reduce the choice of people, it will hurt them.
I suggest to use slightly better wording and get 5.4.0 out.
If somebody has ongoing work on 5.0.x and wants to be even more
conservative, he needs to be able to still find 5.0.x, even when
it is not the recommended stable version anymore.

> > Software can always be better. Waiting with a 5.4 release doesn't
> > make sense as open things are not going to be solved in the
> > near future (shared libs on Mac etc). So, please, let's get 5.4
> > out and "downgrade" 5.0 in it's importance.

For me the criteria would be is 5.4.0 as stable as 5.0.x.
I understand from you that this is the case, thus we can go to 5.4.0.

> The thing is that once 5.4 is released we are going to stop CVS access to
> the grass repository and only work on 5.7. But considering people are
> going to be going on using 5.3 for many many years we still need to fix
> everything that was added since 5.0 but is not finished yet.

We need to keep open CVS for bug fixes on 5.4.x anyway.
A stable version needs to be actively maintained by common standards.
But new features should go into 5.7 then.

> > To have 3 versions on the web site is considered to be very
> > confusing (I heard that many times the last weeks).
>
> Well we can take 5.0 off right now I think.

It should also disappear from the download page then.

As written above: I do not like the idea to have it disappear.

> I think it will greatly reduce the volume of annoying complaints from
> people in the future if we make sure what's there now works, before 5.4.

Mmh. So we better do not look at the bugtracker.

At least browsing for release critical bugs probably is a good thing to so.
(Otherwise complains might be higher resulting in more work.)

Again, we need a new version soon which can be called "stable" according
to the version number. After a 5.4 release bugfixing is obviously possible.
But why adding new features to 5.4 if 5.7 is already there? With 10 more
developers it might be feasible to maintain two versions but currently...

I share that notion.

  Bernhard

If I can put in a small 2 cent's worth, I agree with Bernhard.

Let's go with 5.4 and call it the stable, current release. Keep it open for
bug fixes. For example, I need to fix a few tcltkgrass modules that have
flags with the command lines. But this is a bug fix, not a new feature. I
also agree with Markus about getting rid of the 5.3/5.7 merge procedure.
This complicates updating 5.7 as well as making it confusing for people who
want to compile current CVS versions.

5.0.x can be prior, old, or outdated stable release. (Really need to change
the installation instructions for Cygwin). We don't have to remove it, just
label it appropriately to discourage people from using it--especially new
users without a prior investment in 5.0.

5.7 should go to testing or beta. The rationale is that it is far from an
unstable or even alpha release. It is actually more stable than many
commercial products. However, it is undergoing active development. In any
case, people should not be discouraged from using it by how it is classed,
but be encouraged to do so as much as possible.

Michael

On 9/30/04 9:42 AM, "Bernhard Reiter" <bernhard@intevation.de> wrote:

Hello Markus,

I agree with your assessment that a new stable release is needed
as not much bugfixing is going on for 5.0.x and having three
versions out is not the best solution.

Not having tried 5.3.x much, I cannot evalutate its stability.
Assuming that user feedback is fine we should make it 5.4.0
and then aim for bug-fix releases.

On Thu, Sep 30, 2004 at 04:56:34PM +0200, Markus Neteler wrote:

On Thu, Sep 30, 2004 at 03:32:15PM +0100, Paul Kelly wrote:

On Wed, 29 Sep 2004, Markus Neteler wrote:

Many GRASS users seem to be very conservative concerning version
numbers. I asked several people in Bangkok why they used 5.0.x
and then presented long lists of problems in their conclusions
(most of them are already solved in 5.3/5.7). They answered that
the web pages indicate 5.3 only as testing but 5.0 is indicated
as stable.

Straight away we could delete 5.0 from the list on the
front page leaving only 5.3 and 5.7 I think.

I'll do that if there aren't objections.

No, please do not reduce the choice of people, it will hurt them.
I suggest to use slightly better wording and get 5.4.0 out.
If somebody has ongoing work on 5.0.x and wants to be even more
conservative, he needs to be able to still find 5.0.x, even when
it is not the recommended stable version anymore.

Software can always be better. Waiting with a 5.4 release doesn't
make sense as open things are not going to be solved in the
near future (shared libs on Mac etc). So, please, let's get 5.4
out and "downgrade" 5.0 in it's importance.

For me the criteria would be is 5.4.0 as stable as 5.0.x.
I understand from you that this is the case, thus we can go to 5.4.0.

The thing is that once 5.4 is released we are going to stop CVS access to
the grass repository and only work on 5.7. But considering people are
going to be going on using 5.3 for many many years we still need to fix
everything that was added since 5.0 but is not finished yet.

We need to keep open CVS for bug fixes on 5.4.x anyway.
A stable version needs to be actively maintained by common standards.
But new features should go into 5.7 then.

To have 3 versions on the web site is considered to be very
confusing (I heard that many times the last weeks).

Well we can take 5.0 off right now I think.

It should also disappear from the download page then.

As written above: I do not like the idea to have it disappear.

I think it will greatly reduce the volume of annoying complaints from
people in the future if we make sure what's there now works, before 5.4.

Mmh. So we better do not look at the bugtracker.

At least browsing for release critical bugs probably is a good thing to so.
(Otherwise complains might be higher resulting in more work.)

Again, we need a new version soon which can be called "stable" according
to the version number. After a 5.4 release bugfixing is obviously possible.
But why adding new features to 5.4 if 5.7 is already there? With 10 more
developers it might be feasible to maintain two versions but currently...

I share that notion.

Bernhard

______________________________
Michael Barton, Professor of Anthropology
School of Human Diversity and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

> Straight away we could delete 5.0 from the list on the
> front page leaving only 5.3 and 5.7 I think.

I'll do that if there aren't objections.

none here.

Maybe we could come up with a word more stable than "Testing" for 5.3?

> Well we can take 5.0 off right now I think.

It should also disappear from the download page then.

not disappear, just moved to "old GRASS versions" as 4.3 is now.

Hamish

On Thu, 30 Sep 2004, Markus Neteler wrote:

At least I would like to get rid of the complicated merge
procedure for 5.7 which is hard to explain to non-experts and
also makes RPM packaging difficult.
For that 5.3 has to be sort of frozen.

That actually should be no problem. The parts of 5.3 I would like to still fix up are not actually in 5.7 (e.g. build mechanism and some modules that are not being ported like v.in.dxf.) The same also goes for tcltkgrass. So I suppose if we are going to continue bugfixes on the 5.4 branch, we can make the 5.4.0 copies of everything that is currently 'make mixed' frozen into 5.7. It would be good to do this by moving things around directly in the CVS repository so history is preserved, but I don't know how feasible that is.

Paul

On Fri, Oct 01, 2004 at 11:23:12AM +1200, Hamish wrote:

> > Straight away we could delete 5.0 from the list on the
> > front page leaving only 5.3 and 5.7 I think.
>
> I'll do that if there aren't objections.

none here.

OK, done.

Maybe we could come up with a word more stable than "Testing" for 5.3?

> > Well we can take 5.0 off right now I think.
>
> It should also disappear from the download page then.

not disappear, just moved to "old GRASS versions" as 4.3 is now.

Jup.

Markus

Hello Bernhard

On Thu, 30 Sep 2004, Bernhard Reiter wrote:

Straight away we could delete 5.0 from the list on the
front page leaving only 5.3 and 5.7 I think.

I'll do that if there aren't objections.

No, please do not reduce the choice of people, it will hurt them.
I suggest to use slightly better wording and get 5.4.0 out.
If somebody has ongoing work on 5.0.x and wants to be even more
conservative, he needs to be able to still find 5.0.x, even when
it is not the recommended stable version anymore.

Of course it will still be there, in the list of old versions along with 4.3. I know having 4.3 still available has been very useful to me on several occasions and I don't think there should be any question of deleting the 5.0.x source distributions etc., but 5.0 should not be prominent in the links on the front page IMHO.

For me the criteria would be is 5.4.0 as stable as 5.0.x.
I understand from you that this is the case, thus we can go to 5.4.0.

That is certainly true.

We need to keep open CVS for bug fixes on 5.4.x anyway.
A stable version needs to be actively maintained by common standards.
But new features should go into 5.7 then.

This is already the case I suppose. So by that logic releasing 5.4.0 now would make sense.
The one big thing I would like to change is to make the alternate build mechanism the default for 5.4.0. That will require a few changes to the r.terraflow makefile. We can always recommend OS X users to use --enable-shared=no with 5.4 for now.

I suggest we leave it until the middle of next week to allow some final changes.

It should also disappear from the download page then.

As written above: I do not like the idea to have it disappear.

I feel it should be moved to the 'Old versions' section along with 4.3 etc.

Paul

Hi Paul,

got you wrong on that point then.
Moving it into the old section is of course fine.

(Though currently the links to the old section make
you search a bit until you find it again... )

  Bernhard

On Fri, Oct 01, 2004 at 11:26:57AM +0100, Paul Kelly wrote:

Of course it will still be there, in the list of old versions along with
4.3. I know having 4.3 still available has been very useful to me on
several occasions and I don't think there should be any question of
deleting the 5.0.x source distributions etc., but 5.0 should not be
prominent in the links on the front page IMHO.

>As written above: I do not like the idea to have it disappear.

I feel it should be moved to the 'Old versions' section along with 4.3
etc.

On Fri, Oct 01, 2004 at 09:56:23AM +0100, Paul Kelly wrote:

It would be good to do this by moving things around directly in
the CVS repository so history is preserved, but I don't know how feasible
that is.

I can move files or directories around in CVS in principle.
Just need a good list.
(probably the right mv commands might be most instructive :wink: )
and then I need to schedule shutting down CVS
and doing the change.
(Depending on my time this might a few days, so giving me an ahead
notice is appreceated.)

  Bernhard

On Friday 01 October 2004 13:34, Bernhard Reiter wrote:

On Fri, Oct 01, 2004 at 09:56:23AM +0100, Paul Kelly wrote:
> It would be good to do this by moving things around directly in
> the CVS repository so history is preserved, but I don't know how feasible
> that is.

I can move files or directories around in CVS in principle.
Just need a good list.
(probably the right mv commands might be most instructive :wink: )
and then I need to schedule shutting down CVS
and doing the change.
(Depending on my time this might a few days, so giving me an ahead
notice is appreceated.)

  Bernhard

The list is here:
  http://freegis.org/cgi-bin/viewcvs.cgi/grass51/tools/link.conf?rev=1.72&content-type=text/vnd.viewcvs-markup
excluding *akefiles and subdirs,
  (see http://freegis.org/cgi-bin/viewcvs.cgi/grass51/tools/link?rev=1.8&content-type=text/vnd.viewcvs-markup )
it can still copy unused files, which is not harm, I think.

Should be 'cp', not 'mv', I believe.

Initial comment (probably a new comment appended at the end),
should tell in unique form, where it was taken from (grass5 tree).

Radim

Hello Paul

On Fri, 1 Oct 2004, Paul Kelly wrote:

This is already the case I suppose. So by that logic releasing 5.4.0 now would make sense.
The one big thing I would like to change is to make the alternate build mechanism the default for 5.4.0. That will require a few changes to the r.terraflow makefile. We can always recommend OS X users to use --enable-shared=no with 5.4 for now.

OK for OS X users: this is possible. It's OK if the OS X version has static lib. Now last 5.3cvs is very stable on OS X. The true goal is Grass 5.7: many OS X users already use the 5.7 version.

Bye

--
________________________________________________________________________
|| Lorenzo Moretti e-mail: lorenzo.moretti@bologna.enea.it ||/|/| ENEA prot/idr Web: http://wwwamb.bologna.enea.it/ || | via Don Fiammelli, 2 FTP: ftp://ftpamb.bologna.enea.it/ (ris.)
~~~~~~ 40128 BOLOGNA - ITALY Ph: +39-0516098086 Fax: +39-0516098131
________________________________________________________________________

On Fri, Oct 01, 2004 at 01:57:11PM +0200, Radim Blazek wrote:

On Friday 01 October 2004 13:34, Bernhard Reiter wrote:
> On Fri, Oct 01, 2004 at 09:56:23AM +0100, Paul Kelly wrote:
> > It would be good to do this by moving things around directly in
> > the CVS repository so history is preserved, but I don't know how feasible
> > that is.
>
> I can move files or directories around in CVS in principle.
> Just need a good list.
> (probably the right mv commands might be most instructive :wink: )
> and then I need to schedule shutting down CVS
> and doing the change.
> (Depending on my time this might a few days, so giving me an ahead
> notice is appreceated.)

The list is here:
  http://freegis.org/cgi-bin/viewcvs.cgi/grass51/tools/link.conf?rev=1.72&content-type=text/vnd.viewcvs-markup
excluding *akefiles and subdirs,
  (see http://freegis.org/cgi-bin/viewcvs.cgi/grass51/tools/link?rev=1.8&content-type=text/vnd.viewcvs-markup )
it can still copy unused files, which is not harm, I think.

Should be 'cp', not 'mv', I believe.

Yes!

I would appreciate if someone would make a fixed list of "cp"
command lines that I only need to source with the ",v" extension,
because that seems more transparent as a script.
Especially must there be checking if there is a corresponding file already?

Do you want me to
  mv grass51 grass57
,too?

Initial comment (probably a new comment appended at the end),
should tell in unique form, where it was taken from (grass5 tree).

During a copy operation in the repository someone cannot put in CVS comments,
they would be exactly the same as in the original file.
Probably with cvs admin you can change something.
Maybe basiing revision numbers starting with "2.x" ?

When do you want this to happen?
Next week?
After 5.4 release?
  Bernhard

On Friday 01 October 2004 15:25, Bernhard Reiter wrote:

> > I can move files or directories around in CVS in principle.
> > Just need a good list.
> > (probably the right mv commands might be most instructive :wink: )
> > and then I need to schedule shutting down CVS
> > and doing the change.
> > (Depending on my time this might a few days, so giving me an ahead
> > notice is appreceated.)
>
> The list is here:
>
> http://freegis.org/cgi-bin/viewcvs.cgi/grass51/tools/link.conf?rev=1.72&c
>ontent-type=text/vnd.viewcvs-markup excluding *akefiles and subdirs,
> (see
> http://freegis.org/cgi-bin/viewcvs.cgi/grass51/tools/link?rev=1.8&content
>-type=text/vnd.viewcvs-markup ) it can still copy unused files, which is
> not harm, I think.
>
> Should be 'cp', not 'mv', I believe.

Yes!

I would appreciate if someone would make a fixed list of "cp"
command lines that I only need to source with the ",v" extension,
because that seems more transparent as a script.
Especially must there be checking if there is a corresponding file already?

Yes.

Do you want me to
  mv grass51 grass57
,too?

No.

> Initial comment (probably a new comment appended at the end),
> should tell in unique form, where it was taken from (grass5 tree).

During a copy operation in the repository someone cannot put in CVS
comments, they would be exactly the same as in the original file.
Probably with cvs admin you can change something.
Maybe basiing revision numbers starting with "2.x" ?

When do you want this to happen?
Next week?
After 5.4 release?

Radim

Hi

I am wondering if there is a raster to vector converter for text like there is for lines?

thanks
Stephen

Bernhard Reiter wrote:

> The list is here:
> http://freegis.org/cgi-bin/viewcvs.cgi/grass51/tools/link.conf?rev=1.72&content-type=text/vnd.viewcvs-markup
> excluding *akefiles and subdirs,
> (see http://freegis.org/cgi-bin/viewcvs.cgi/grass51/tools/link?rev=1.8&content-type=text/vnd.viewcvs-markup )
> it can still copy unused files, which is not harm, I think.
>
> Should be 'cp', not 'mv', I believe.

Yes!

I would appreciate if someone would make a fixed list of "cp"
command lines that I only need to source with the ",v" extension,
because that seems more transparent as a script.
Especially must there be checking if there is a corresponding file already?

The simplest solution would probably be to either:

a) modify the tools/link script to emit a "cp" command whenever it
would normally execute "ln -s", or

b) run "make mix" then "find . -type l ..." and generate a cp command
for each link found.

--
Glynn Clements <glynn.clements@virgin.net>

I am wondering if there is a raster to vector converter for text like
there is for lines?

r.out.tiff and generic OCR software?
what exactly are you trying to do?

Hamish