[GRASS5] Re: [GRASS-CVS] CVS update: grass/src/mapdev/v.llabel

On Wednesday 08 May 2002 05:42 pm, you wrote:

Ciao Radim,

roger has fixed it - ok now?

Markus

1) v.llabel map=pok
Error: value <all> out of range for parameter <type>
       Legal range: point,line,edge

2) Was not commited to HEAD.

Sorry Roger, I don't want to discourage you, to contribute to grass,
but module should be probably run, before changes are commited,
and that all fixes in release branch MUST be commited to HEAD, is
obvious (I hope, am I right? - I never know what will be the future
of branches).

Radim

On Wed, May 08, 2002 at 05:02:36PM +0200, grass@intevation.de wrote:
> Date: Wednesday May 8, 2002 @ 15:02
> Author: roger
>
> Update of /grassrepository/grass/src/mapdev/v.llabel
> In directory doto:/tmp/cvs-serv19926
>
> Modified Files:
> Tag: releasebranch_26_april_2002_5_0_0
> main.c
> Log Message:
> Changed a bad "options" string
>
> _______________________________________________
> grass-commit mailing list
> grass-commit@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-commit

[NB: I've committed the fix to the head.]

Radim Blazek wrote:

1) v.llabel map=pok
Error: value <all> out of range for parameter <type>
       Legal range: point,line,edge

2) Was not commited to HEAD.

Sorry Roger, I don't want to discourage you, to contribute to grass,
but module should be probably run, before changes are commited,
and that all fixes in release branch MUST be commited to HEAD, is
obvious (I hope, am I right? - I never know what will be the future
of branches).

In general, changes should be committed to the head first. Only once
they've had sufficient testing should they be committed to the release
branch.

However, if the change is a simple fix for a definite bug (as is the
case here), it can be committed to the head and to the release branch
simultaneously.

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

On Thu, May 09, 2002 at 08:55:08AM +0100, Glynn Clements wrote:

[NB: I've committed the fix to the head.]

Radim Blazek wrote:

> 1) v.llabel map=pok
> Error: value <all> out of range for parameter <type>
> Legal range: point,line,edge
>
> 2) Was not commited to HEAD.
>
> Sorry Roger, I don't want to discourage you, to contribute to grass,
> but module should be probably run, before changes are commited,
> and that all fixes in release branch MUST be commited to HEAD, is
> obvious (I hope, am I right? - I never know what will be the future
> of branches).

In general, changes should be committed to the head first. Only once
they've had sufficient testing should they be committed to the release
branch.

However, if the change is a simple fix for a definite bug (as is the
case here), it can be committed to the head and to the release branch
simultaneously.

Glynn,

would you mind to post (another time?) the cvs-sync-with-releasebranch
command line (I can't find your last mail on that any more)?
It was cvs -j something (to be invoked in HEAD, right)?

Thanks,

Markus

Markus Neteler wrote:

> > 1) v.llabel map=pok
> > Error: value <all> out of range for parameter <type>
> > Legal range: point,line,edge
> >
> > 2) Was not commited to HEAD.
> >
> > Sorry Roger, I don't want to discourage you, to contribute to grass,
> > but module should be probably run, before changes are commited,
> > and that all fixes in release branch MUST be commited to HEAD, is
> > obvious (I hope, am I right? - I never know what will be the future
> > of branches).
>
> In general, changes should be committed to the head first. Only once
> they've had sufficient testing should they be committed to the release
> branch.
>
> However, if the change is a simple fix for a definite bug (as is the
> case here), it can be committed to the head and to the release branch
> simultaneously.

would you mind to post (another time?) the cvs-sync-with-releasebranch
command line (I can't find your last mail on that any more)?
It was cvs -j something (to be invoked in HEAD, right)?

To merge all release branch changes into the head, use:

  cvs update -j branch_tag:date -j branch_tag
or
  cvs update -j snapshot_tag -j branch_tag

from within working copy of the head. "branch_tag" is the branch tag,
i.e. releasebranch_26_april_2002_5_0_0. "snapshot_tag" is a non-branch
tag which has been applied to the release branch, and "date" is a date
acceptable to the cvs "-D" switch.

Either the date or the snapshot tag must refer to the previous
synchronisation. The simple solution is to use the tag form, and add a
tag immediately after each sync.

Note that this approach is mutually exclusive with synchronising
individual changes (i.e. committing to both the release branch and the
head). If you attempt to sync changes to a working copy which already
has those changes, it will usually result in a conflict (however, it's
theoretically possible, although unlikely, that it will silently break
the working copy).

Basically, "cvs update -j ... -j ..." is equivalent to
"cvs diff -r ... -r ... | patch -p0"; it determines the changes
between two "snapshots" of the code, then applies the changes to the
working copy.

Also note that CVS keyword expansion can result in unnecessary
conflicts. You can use "-kk" to override keyword expansion. However,
this option is sticky (at least in normal use of "cvs update"; I'm not
sure about merging), so you may need to use "cvs update -A" afterwards
to clear it.

Merging is described in detail in the node "Branching and merging" in
the "cvs" Info file.

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

On Thursday 09 May 2002 01:11, Radim wrote:

Sorry Roger, I don't want to discourage you, to contribute to grass,
but module should be probably run, before changes are commited,

I thought I made it clear to the list that I was currently unable to test the
change, but I was encouraged to commit the change anyway. After all, the
code was broken to start with and committing still broken code didn't make
anything worse and had a chance of helping.

and that all fixes in release branch MUST be commited to HEAD, is
obvious (I hope, am I right? - I never know what will be the future
of branches).

I committed it to the release branch because discussion on this list lead me
to believe the release branch would be merged back into HEAD after the
release was made. If we can work only on release-critical bugs and we have
to commit to both branches then the release branch would seem to be
superfluous.

Roger Miller

On Thu, May 09, 2002 at 05:02:48AM -0600, Roger Miller wrote:

On Thursday 09 May 2002 01:11, Radim wrote:

> Sorry Roger, I don't want to discourage you, to contribute to grass,
> but module should be probably run, before changes are commited,

I thought I made it clear to the list that I was currently unable to test the
change, but I was encouraged to commit the change anyway. After all, the
code was broken to start with and committing still broken code didn't make
anything worse and had a chance of helping.

Yes, this was okay.
Radim: I told Roger to commit this as the code was broken anyway.
Thus I'm the one to critise here, because Roger asked first.
I still think it was correct, as it was the only chance for Roger to
help us. He just should have committed the same fix to HEAD.

> and that all fixes in release branch MUST be commited to HEAD, is
> obvious (I hope, am I right?

Yes, you are right.

I committed it to the release branch because discussion on this list lead me
to believe the release branch would be merged back into HEAD after the
release was made. If we can work only on release-critical bugs and we have
to commit to both branches then the release branch would seem to be
superfluous.

Making sure that each change is made in the release branch
and in HEAD, is like merging each change in a way.

We need the release branch, because HEAD is more advanced.
So the fix for the Release branch might not be the same for the HEAD branch.
You can work on other bugs and smaller enhancement on HEAD.

Fixed now (I hope), in both (I hope).

Radim

On Thursday 09 May 2002 03:53 pm, Bernhard Reiter wrote:

On Thu, May 09, 2002 at 05:02:48AM -0600, Roger Miller wrote:
> On Thursday 09 May 2002 01:11, Radim wrote:
> > Sorry Roger, I don't want to discourage you, to contribute to grass,
> > but module should be probably run, before changes are commited,
>
> I thought I made it clear to the list that I was currently unable to test
> the change, but I was encouraged to commit the change anyway. After all,
> the code was broken to start with and committing still broken code didn't
> make anything worse and had a chance of helping.

Yes, this was okay.
Radim: I told Roger to commit this as the code was broken anyway.
Thus I'm the one to critise here, because Roger asked first.
I still think it was correct, as it was the only chance for Roger to
help us. He just should have committed the same fix to HEAD.

> > and that all fixes in release branch MUST be commited to HEAD, is
> > obvious (I hope, am I right?

Yes, you are right.

> I committed it to the release branch because discussion on this list lead
> me to believe the release branch would be merged back into HEAD after the
> release was made. If we can work only on release-critical bugs and we
> have to commit to both branches then the release branch would seem to be
> superfluous.

Making sure that each change is made in the release branch
and in HEAD, is like merging each change in a way.

We need the release branch, because HEAD is more advanced.
So the fix for the Release branch might not be the same for the HEAD
branch. You can work on other bugs and smaller enhancement on HEAD.

----------------------------------------
Content-Type: application/pgp-signature; charset="us-ascii";
name="Attachment: 1"
Content-Transfer-Encoding: 7bit
Content-Description:
----------------------------------------

On Thu, May 09, 2002 at 04:33:18PM +0200, Radim Blazek wrote:

Fixed now (I hope), in both (I hope).

Cool, thanks.
From reading the CVS commit messages in the last day,
it seems the Glynn, you and Markus are the most active
bug fixers right now!