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

[Glynn Clements]

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 at virgin.net>