Key fixes include improved portability for MS-Windows
(native support), hundreds of fixes, TclTk based
portable graphical interface and much new functionality.
I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?
Michael
On 10/23/07 3:31 PM, "Markus Neteler" <neteler@fbk.eu> wrote:
A first release candidate of GRASS 6.3.0 is now available:
Key fixes include improved portability for MS-Windows
(native support), hundreds of fixes, TclTk based
portable graphical interface and much new functionality.
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?
Add them to the head first, then back-port to the release branch after
testing.
The quickest way to get the release branch is to make a copy of the
head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.
To sync changes from the trunk to a branch, use "cvs update" with two
-j switches, e.g.:
I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?
I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?
Add them to the head first, then back-port to the release branch after
testing.
The quickest way to get the release branch is to make a copy of the
head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.
To sync changes from the trunk to a branch, use "cvs update" with two
-j switches, e.g.:
>> I looked at your announcement for the 6.3 release. It is excellent. I
>> noticed several new modules that have been missed in the menu and need to be
>> added. Can I just add them to the current grass6 cvs source I've been
>> working with for 6.3 or do I need to check out another source tree for a
>> release branch to add them?
>
> Add them to the head first, then back-port to the release branch after
> testing.
>
> The quickest way to get the release branch is to make a copy of the
> head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.
>
> To sync changes from the trunk to a branch, use "cvs update" with two
> -j switches, e.g.:
>
> cvs update -j releasebranch_6_3 -j HEAD
>
> This is roughly equivalent to:
>
> cvs diff -r releasebranch_6_3 -r HEAD | patch -p0
I followed your instructions to send some changes to both head and
release branch. Files were updated in my local releasebranch copy, but
doesn't seem to have changed in repository (or I'm looking in the wrong
place).
Both of the above only update the local copy; you need to use
"cvs commit" to actually commit the changes.
I looked at your announcement for the 6.3 release. It is excellent. I
noticed several new modules that have been missed in the menu and need to be
added. Can I just add them to the current grass6 cvs source I've been
working with for 6.3 or do I need to check out another source tree for a
release branch to add them?
Add them to the head first, then back-port to the release branch after
testing.
The quickest way to get the release branch is to make a copy of the
head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.
To sync changes from the trunk to a branch, use "cvs update" with two
-j switches, e.g.:
cvs update -j releasebranch_6_3 -j HEAD
This is roughly equivalent to:
cvs diff -r releasebranch_6_3 -r HEAD | patch -p0
I followed your instructions to send some changes to both head and release branch. Files were updated in my local releasebranch copy, but doesn't seem to have changed in repository (or I'm looking in the wrong place).
Both of the above only update the local copy; you need to use
"cvs commit" to actually commit the changes.
Yes, but the problem is I did "cvs ci" from releasebranch copy and it did nothing.
>>>> I looked at your announcement for the 6.3 release. It is excellent. I
>>>> noticed several new modules that have been missed in the menu and need to be
>>>> added. Can I just add them to the current grass6 cvs source I've been
>>>> working with for 6.3 or do I need to check out another source tree for a
>>>> release branch to add them?
>>>>
>>> Add them to the head first, then back-port to the release branch after
>>> testing.
>>>
>>> The quickest way to get the release branch is to make a copy of the
>>> head (cp -a) then run "cvs update -r releasebranch_6_3" in the copy.
>>>
>>> To sync changes from the trunk to a branch, use "cvs update" with two
>>> -j switches, e.g.:
>>>
>>> cvs update -j releasebranch_6_3 -j HEAD
>>>
>>> This is roughly equivalent to:
>>>
>>> cvs diff -r releasebranch_6_3 -r HEAD | patch -p0
>>>
>> I followed your instructions to send some changes to both head and
>> release branch. Files were updated in my local releasebranch copy, but
>> doesn't seem to have changed in repository (or I'm looking in the wrong
>> place).
>>
>
> Both of the above only update the local copy; you need to use
> "cvs commit" to actually commit the changes.
Yes, but the problem is I did "cvs ci" from releasebranch copy and it
did nothing.
First, check that your local copy is of the release branch, not the
trunk (or a specific release), by looking at the CVS/Tag and
CVS/Entries files for the directory in question. The former should
contain Treleasebranch_6_3, while the latter should have that tag at
the end of each entries.
Also, using "cvs update -j ... -j ..." assumes that you have already
committed the changes to the trunk. To clarify:
1. Make changes to the local copy of the trunk.
2. Commit the changes.
3. Change directory to the local copy of the branch.
4. Use "cvs update -j ... -j ..." to synchronise the branch to the
trunk.
5. Commit the changes.
Some pedantic but by my experience useful steps added below,
(lessons learned as I messed things up at each one of these steps in the past)
Glynn wrote:
To clarify:
0. 'cvs update' to be sure you are working with the latest version.
1. Make changes to the local copy of the trunk.
1.5 'cvs diff' to check for left over temporary debug messages, unnecessary
whitespace changes, etc.
2. Commit the changes.
2.5. Decide if the change is suitable for backporting.
3. Change directory to the local copy of the branch.
4. Use "cvs update -j ... -j ..." to synchronise the branch to the
trunk.
4.5 'cvs diff' check again.
5. Commit the changes.
As to deciding what is suitable for backporting, I am of two minds. On one hand
it is very useful to have some sort of deadline to motivate us to fix as many
old lingering bugs as possible before the release. On the other hand even small
modifications to critical modules like g.region and r.out.gdal days before
release are very dangerous. Those need maximum testing time in the development
branch to avoid nasty unintentional side effects. It has been typical for that
sort of mistake not to be spotted even in the well tested CVS/HEAD version for
months.
A good rule seems to be only backport important bug fixes and well-tested
important updates. Leave anything else to a future release. 6.3.0 is not
intended to be as stable as 6.2, so I wouldn't worry so much about that here,
for 6.3 it becomes more a question of if the backporting justifies the double
effort.
The stable branch CVS mostly goes untested before release, so any change there
has to be very carefully done.
Hamish
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
I'd like to get the SoC project included into the 6.3.0 release. Anybody
mind if I put them in the CVS from the SVN?
Ideally I'd have liked to wait for the gmath changes (since v.generalize
can be optimized after that), but I think it is more important to get
the SoC project in our next release (simply so that we can show next
year to the students that if they do good, their code ends up in the
next release).
--Wolf
On 24.10.2007 01:31, Markus Neteler wrote:
A first release candidate of GRASS 6.3.0 is now available:
Key fixes include improved portability for MS-Windows
(native support), hundreds of fixes, TclTk based
portable graphical interface and much new functionality.
On Oct 25, 2007, at 2:41 AM, Wolf Bergenheim wrote:
Hi!
I'd like to get the SoC project included into the 6.3.0 release. Anybody
mind if I put them in the CVS from the SVN?
I am very much in support of that - but has anybody besides Wolf and me tested them?
Especially with some other data than spearfish or the new nc data set?
(e.g. latlong, very small scale etc.).
Helena
Ideally I'd have liked to wait for the gmath changes (since v.generalize
can be optimized after that), but I think it is more important to get
the SoC project in our next release (simply so that we can show next
year to the students that if they do good, their code ends up in the
next release).
--Wolf
On 24.10.2007 01:31, Markus Neteler wrote:
A first release candidate of GRASS 6.3.0 is now available:
Key fixes include improved portability for MS-Windows
(native support), hundreds of fixes, TclTk based
portable graphical interface and much new functionality.
Hi,
I used v.generalize to clean-up some data for ArcGIS users and it
worked like charm. 6.3.0 isn't a stable release - it's a
stable-unstable version It may bring some breakage to 6.3, but
still I would love to see v.generalize in main 6.3.0 release (even if
it means to wait another week before final version is out).
WBR,
Maris.
2007/10/25, Helena Mitasova <hmitaso@unity.ncsu.edu>:
On Oct 25, 2007, at 2:41 AM, Wolf Bergenheim wrote:
> Hi!
>
> I'd like to get the SoC project included into the 6.3.0 release.
> Anybody
> mind if I put them in the CVS from the SVN?
I am very much in support of that - but has anybody besides Wolf and
me tested them?
Especially with some other data than spearfish or the new nc data set?
(e.g. latlong, very small scale etc.).
Some pedantic but by my experience useful steps added below,
(lessons learned as I messed things up at each one of these steps in the past)
Glynn wrote:
To clarify:
0. 'cvs update' to be sure you are working with the latest version.
1. Make changes to the local copy of the trunk.
1.5 'cvs diff' to check for left over temporary debug messages, unnecessary
whitespace changes, etc.
2. Commit the changes.
2.5. Decide if the change is suitable for backporting.
3. Change directory to the local copy of the branch.
4. Use "cvs update -j ... -j ..." to synchronise the branch to the
trunk.
4.5 'cvs diff' check again.
5. Commit the changes.
Perfectly clear now, thanks both of you
As to deciding what is suitable for backporting, I am of two minds. On one hand
it is very useful to have some sort of deadline to motivate us to fix as many
old lingering bugs as possible before the release. On the other hand even small
modifications to critical modules like g.region and r.out.gdal days before
release are very dangerous. Those need maximum testing time in the development
branch to avoid nasty unintentional side effects. It has been typical for that
sort of mistake not to be spotted even in the well tested CVS/HEAD version for
months.
A good rule seems to be only backport important bug fixes and well-tested
important updates. Leave anything else to a future release. 6.3.0 is not
intended to be as stable as 6.2, so I wouldn't worry so much about that here,
for 6.3 it becomes more a question of if the backporting justifies the double
effort.
My changes only affect internationalized messages, so they neither fix important bugs nor should create them, so the effort is the only thing in mind.
Thanks again for the information.
Carlos
It may bring some breakage to 6.3, but