[GRASS-dev] 6.3.0 backport question

Hi,

I have seen a set of fixes in the CVS which haven't been backported
yet. So far I didn't figure out the magic line to push a fix
from HEAD to release branch.

Anyone who can teach me? Glynn once posted it but it didn't
seem to work for me.
Certainly it would be better is *all* developers made use of
the magic push line to avoid that others accidentally port
irrelevant stuff or simply to save us/me time.

Markus

Markus Neteler wrote:

I have seen a set of fixes in the CVS which haven't been backported
yet.

Is there a policy for 6.3.0 backports? Bugfixes only? Minor fixes? New
features? Cool stuff? Everything?

So far I didn't figure out the magic line to push a fix
from HEAD to release branch.

Anyone who can teach me? Glynn once posted it but it didn't
seem to work for me.

Perhaps not the perfect way, but

- commit change in HEAD
- cd releasebranch_6_3/
- cvs co -r releasebranch_6_3 grass6/file/to/change
# IFF there has not been previous changes to the file in the branch
- cvs up -j HEAD grass6/file/to/change
- cvs diff grass6/file/to/change
- cvs commit grass6/file/to/change

If there have been prior changes to the branch you need to also specify the
release branch revision, as detailed in Glynn's prior post. Otherwise you get
conflicts during the merge. In those cases I admit that I usually revert to
doing a surgical edit in vi + cvs diff rather than try to make sense of the
mixed lineage. The downside is this requires a human & thus some level of human
error may be introduces.

Certainly it would be better is *all* developers made use of
the magic push line to avoid that others accidentally port
irrelevant stuff or simply to save us/me time.

FWIW, my strategy has been to backport bug fixes only and if there are a series
of changes wait for the dust to settle and backport all the changes at once
instead of for each of a series of refinements. The downside is sometimes after
a couple of days of settled dust I forget about it...

For recent MS Windows fixes, I think it is ok for 6.3.0 to be considered alpha1
release, and 6.3.1 can be alpha2. Do we backport all DOS changes or split off
6.3.1(MS-alpha2) as another branch from HEAD?

Hamish

      ____________________________________________________________________________________
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

Markus Neteler wrote:

I have seen a set of fixes in the CVS which haven't been backported
yet. So far I didn't figure out the magic line to push a fix
from HEAD to release branch.

This normally works (from the branch):

  cvs update -j HEAD <filename>
  cvs commit <filename>

There can be problems if you want to merge a file more than once after
it has been branched, but I don't recall whether it affects the case
of merging from the trunk to a branch (the CVS documentation only
covers merging a branch into the trunk).

Using two -j flags with explicit revision numbers will always work,
but that's awkward for changes which span multiple files. I have had
problems with the "-j branch:date" form; an alternative is to tag by
date then merge using the tag.

As a fallback, you can use "cvs diff" to extract the changes as a
patch, then manually apply it to the branch.

--
Glynn Clements <glynn@gclements.plus.com>

Hamish wrote on 11/13/2007 01:55 AM:

Markus Neteler wrote:
  

I have seen a set of fixes in the CVS which haven't been backported
yet.
    
Is there a policy for 6.3.0 backports? Bugfixes only? Minor fixes? New
features? Cool stuff? Everything?

I think that the common backport strategy applies: Bugfixes only.

I'll try Glynn's cvs cmd line suggestion to backport some missing
fixes.

Markus

Markus Neteler wrote:

Hamish wrote on 11/13/2007 01:55 AM:

Markus Neteler wrote:

I have seen a set of fixes in the CVS which haven't been backported
yet.

Is there a policy for 6.3.0 backports? Bugfixes only? Minor fixes? New
features? Cool stuff? Everything?

I think that the common backport strategy applies: Bugfixes only.

I'll try Glynn's cvs cmd line suggestion to backport some missing
fixes.

If I backported a commit or two in the meantime would it
interfere with your work?

Maciek

Glynn Clements wrote:

Markus Neteler wrote:

I have seen a set of fixes in the CVS which haven't been backported
yet. So far I didn't figure out the magic line to push a fix
from HEAD to release branch.

This normally works (from the branch):

  cvs update -j HEAD <filename>
  cvs commit <filename>

I have tried this in
macosx/app/
and then run 'diff -ru ...' on it against HEAD. They are not identical.

Confused,
Markus

PS: Yes, usually I extract the diffs from the commit emails but that's
rather tiring.
--
View this message in context: http://www.nabble.com/6.3.0-backport-question-tf4794403.html#a13782298
Sent from the Grass - Dev mailing list archive at Nabble.com.

Maciej Sieczka wrote:

Markus Neteler wrote:

Hamish wrote on 11/13/2007 01:55 AM:

Markus Neteler wrote:

I have seen a set of fixes in the CVS which haven't been backported
yet.

Is there a policy for 6.3.0 backports? Bugfixes only? Minor fixes? New
features? Cool stuff? Everything?

I think that the common backport strategy applies: Bugfixes only.

I'll try Glynn's cvs cmd line suggestion to backport some missing
fixes.

If I backported a commit or two in the meantime would it
interfere with your work?

Please go ahead! I will instantly see from the commit mailing list
which fix is already done.

thanks
Markus
--
View this message in context: http://www.nabble.com/6.3.0-backport-question-tf4794403.html#a13782314
Sent from the Grass - Dev mailing list archive at Nabble.com.

Markus Neteler wrote:

>> I have seen a set of fixes in the CVS which haven't been backported
>> yet. So far I didn't figure out the magic line to push a fix
>> from HEAD to release branch.
>
> This normally works (from the branch):
>
> cvs update -j HEAD <filename>
> cvs commit <filename>
>

I have tried this in
macosx/app/
and then run 'diff -ru ...' on it against HEAD. They are not identical.

If I do:

  cd /usr/local/src/grass/cvs # HEAD
  cvs update
  cd /usr/local/src/grass/6.3 # releasebranch_6_3
  cvs update
  cd macosx/app
  cvs update -j HEAD
  cd /usr/local/src/grass
  diff -rq {6.3,cvs}/macosx/app

the only differences are in the CVS/* files (Tag and Entries).

It may be worth updating the directories with "cvs update -A" and
"cvs update -r releasebranch_6_3" respectively to ensure that you
don't have any incorrect sticky tags.

--
Glynn Clements <glynn@gclements.plus.com>

Glynn Clements wrote:

It may be worth updating the directories with "cvs update -A" and
"cvs update -r releasebranch_6_3" respectively to ensure that you
don't have any incorrect sticky tags.

Good point. And probably I just had lagging behind my local HEAD
copy. I'll double check and try again.

Markus
--
View this message in context: http://www.nabble.com/6.3.0-backport-question-tf4794403.html#a13795472
Sent from the Grass - Dev mailing list archive at Nabble.com.