Branching

Branching

[Russell Shaw]

Hi,

I made a new remote target for gdb that runs a hardware in-circuit
emulator. I might add a software simulator target too.

Is it usual to create a 'branch' of gdb for this? The files i
work on are new ones that aren't a normal part of gdb.

Re: Branching

[Paul Schlie]

> Russell Shaw wrote:
> I made a new remote target for gdb that runs a hardware in-circuit
> emulator. I might add a software simulator target too.
>
> Is it usual to create a 'branch' of gdb for this? The files i
> work on are new ones that aren't a normal part of gdb.

Sounds interesting, but out of curiosity, why need a branch, as opposed
to aggregating target specific files into a configuration/ target-specific
directory, (just as arguably many of the target-specific files presently
scattered throughout gdb's source directory could/should also be)?

Re: Branching

[Russell Shaw]

Paul Schlie wrote:
>>Russell Shaw wrote:
>>I made a new remote target for gdb that runs a hardware in-circuit
>>emulator. I might add a software simulator target too.
>>
>>Is it usual to create a 'branch' of gdb for this? The files i
>>work on are new ones that aren't a normal part of gdb.
> 
> 
> Sounds interesting, but out of curiosity, why need a branch, as opposed
> to aggregating target specific files into a configuration/ target-specific
> directory, (just as arguably many of the target-specific files presently
> scattered throughout gdb's source directory could/should also be)?

I only followed the way things are currently done with files for other
remote targets.

The only reason for considering a branch is i thought maybe there was
some standard way of accessing it from where ever gdb sources are
currently hosted (i haven't done much cvs stuff).

Section 15 of gdbint manual talks of branches:

   15.4.1 Guidelines
   gdb permits the creation of branches, cut from the cvs repository, for experimental develop-
   ment. Branches make it possible for developers to share preliminary work, and maintainers
   to examine signicant new developments.

      The following are a set of guidelines for creating such branches:
   a branch has an owner...



I was wondering if "experimental development" included adding new targets to gdb,
without modifying the existing gdb files. Having an experimental branch could make
it easier for one to check it out and work on it. The only other way i suppose is
to keep the patches on sourceforge or somewhere?

branching

[David Carlton]

On Tue, 17 Sep 2002 15:24:10 -0400, Andrew Cagney
<ac131313@ges.redhat.com> said:

> For branching, check the CVS man pages and:
> http://sources.redhat.com/gdb/current/onlinedocs/gdbint_15.html#SEC141
> but that is overkill --- you don't need the -D flag.  So something like:

> cvs -d :ext:sources.redhat.com:/cvs/src rtag
> carlton_something-YYYYMMDD-branchpoint gdb+dejagnu

> cvs -d :ext:sources.redhat.com:/cvs/src rtag -b -r
> carlton_something-YYYYMMDD-branchpoint
> carlton_something-YYYYMMDD-branch gdb+dejagnu

> cvs -d :ext:sources.redhat.com:/cvs/src co -r
> carlton_something-YYYYMMDD-branch gdb+dejagnu

Okay, I've read the appropriate documentation, and I might understand
both what I want to type to create the branch and what I want to type
when I want to merge from the mainline into my branch.  But I want to
run it by you, both because I really don't quite understand the
details of merging in from mainline to my branch and because it
differs slightly from the above (albeit only in naming conventions).

All my 'cvs' commands will really be 'cvs -d
:ext:carlton@sources.redhat.com:/cvs/src'.

To create the branch, I plan to:

1) Create a tag saying where the branch will start:

  cvs rtag carlton-dictionary-YYYYMMDD-branchpoint gdb+dejagnu

2) Create the branch:

  cvs rtag -b -r carlton-dictionary-YYYYMMDD-branchpoint
    carlton-dictionary-branch gdb+dejagnu

3) Check out the branch: go to a different directory, and then do

  cvs co -r carlton-dictionary-branch gdb+dejagnu


And to merge changes in from mainline, here's what I might do, but I'm
confused by it:

(All commands assume I'm in the branch's working directory, though it
shouldn't matter for the first command.)

1) Create a tag saying where the merges should end:

  cvs rtag carlton-dictionary-YYYYMMDD-tag gdb+dejagnu

2) Merge in changes from my previous merge tag to the current merge
   tag:

  cvs update -j carlton-dictionary-PreviousYYYYMMDD-tag
    -j carlton-dictionary-YYYYMMDD-tag

   (The first time I do this, the first -tag will actually be
   -branchpoint.)

3) Resolve inconsistencies, and then commit:

  cvs commit


But I'm not at all sure that this is right: how does it know that the
tags that I've added apply to the mainline, or if they apply to all
branches at that particular time, then how do I specify that I want to
merge in from the mainline?  (At first, I'd assumed that I'd do 'cvs
rtag' from a directory that is on the mainline, but the documentation
seems to say that rtag ignores your current working directory.)  The
examples in the CVS manual talk about merging from a branch to a
mainline, but I'm in the reverse situation, and I don't know how to
refer to mainline explicitly, just how to refer to a branch
explicitly.

Also, some minor differences from what you suggested:

1) I'm not sure why it would be a good idea to put a date stamp in the
   name of my branch.

2) It seems to me that, do do this branching and merging, I'll have to
   tag mainline every once in a while; so I'm having the tags end in
   -tag.  You suggested having the initial tag end in -branchpoint,
   which makes sense to me, so I'll do that.  But if you'd prefer a
   name other than -tag for my subsequent merge tags, that's fine with
   me too.  (-mergepoint?)

Once I get this figured out (and have a few merges under my belt),
should I write it up for the Internals manual?

David Carlton
carlton@math.stanford.edu

Re: branching

[Kevin Buettner]

On Sep 19, 12:12pm, David Carlton wrote:

> And to merge changes in from mainline, here's what I might do, but I'm
> confused by it:
> 
> (All commands assume I'm in the branch's working directory, though it
> shouldn't matter for the first command.)
> 
> 1) Create a tag saying where the merges should end:
> 
>   cvs rtag carlton-dictionary-YYYYMMDD-tag gdb+dejagnu
> 
> 2) Merge in changes from my previous merge tag to the current merge
>    tag:
> 
>   cvs update -j carlton-dictionary-PreviousYYYYMMDD-tag
>     -j carlton-dictionary-YYYYMMDD-tag
> 
>    (The first time I do this, the first -tag will actually be
>    -branchpoint.)

Maybe I'm being naive, but why can't you just checkout your branch,
and then do:

    cvs update -j HEAD

Kevin

Re: branching

[David Carlton]

On Thu, 19 Sep 2002 12:30:26 -0700, Kevin Buettner <kevinb@redhat.com> said:
> On Sep 19, 12:12pm, David Carlton wrote:
>> And to merge changes in from mainline, here's what I might do, but I'm
>> confused by it:
>> 
>> (All commands assume I'm in the branch's working directory, though it
>> shouldn't matter for the first command.)
>> 
>> 1) Create a tag saying where the merges should end:
>> 
>> cvs rtag carlton-dictionary-YYYYMMDD-tag gdb+dejagnu
>> 
>> 2) Merge in changes from my previous merge tag to the current merge
>> tag:
>> 
>> cvs update -j carlton-dictionary-PreviousYYYYMMDD-tag
>> -j carlton-dictionary-YYYYMMDD-tag
>> 
>> (The first time I do this, the first -tag will actually be
>> -branchpoint.)

> Maybe I'm being naive, but why can't you just checkout your branch,
> and then do:

>     cvs update -j HEAD

Ah: maybe that's part of the answer: maybe I should do

  cvs update -j carlton-dictionary-YYYYMMDD-tag -j HEAD

(I'd missed the keyword HEAD.)

Section 5.7 of the CVS manual suggests that what you say isn't a good
idea, because it claims that CVS will try to merge in all changes to
head since the original branch, rather than all changes since I last
merged.  If that's accurate, I need to get tags on the head somehow so
that it doesn't try to merge in changes twice.

David Carlton
carlton@math.stanford.edu

Re: branching

[Kevin Buettner]

On Sep 19, 12:35pm, David Carlton wrote:

> > Maybe I'm being naive, but why can't you just checkout your branch,
> > and then do:
> 
> >     cvs update -j HEAD
> 
> Ah: maybe that's part of the answer: maybe I should do
> 
>   cvs update -j carlton-dictionary-YYYYMMDD-tag -j HEAD
> 
> (I'd missed the keyword HEAD.)
> 
> Section 5.7 of the CVS manual suggests that what you say isn't a good
> idea, because it claims that CVS will try to merge in all changes to
> head since the original branch, rather than all changes since I last
> merged.

I see.  That sounds right.

> If that's accurate, I need to get tags on the head somehow so
> that it doesn't try to merge in changes twice.

Maybe just keep track of the date of the last merge and do:

    cvs update -j HEAD:date -j HEAD

Another approach might be to use the -F option with ``cvs tag'' so that
you only need one merge tag (for your branch) on the mainline.

(If you try the -j HEAD:date approach, let me know how it works...)

Kevin

Re: branching

[Daniel Jacobowitz]

On Thu, Sep 19, 2002 at 01:07:46PM -0700, Kevin Buettner wrote:
> On Sep 19, 12:35pm, David Carlton wrote:
> 
> > > Maybe I'm being naive, but why can't you just checkout your branch,
> > > and then do:
> > 
> > >     cvs update -j HEAD
> > 
> > Ah: maybe that's part of the answer: maybe I should do
> > 
> >   cvs update -j carlton-dictionary-YYYYMMDD-tag -j HEAD
> > 
> > (I'd missed the keyword HEAD.)
> > 
> > Section 5.7 of the CVS manual suggests that what you say isn't a good
> > idea, because it claims that CVS will try to merge in all changes to
> > head since the original branch, rather than all changes since I last
> > merged.
> 
> I see.  That sounds right.
> 
> > If that's accurate, I need to get tags on the head somehow so
> > that it doesn't try to merge in changes twice.
> 
> Maybe just keep track of the date of the last merge and do:
> 
>     cvs update -j HEAD:date -j HEAD
> 
> Another approach might be to use the -F option with ``cvs tag'' so that
> you only need one merge tag (for your branch) on the mainline.
> 
> (If you try the -j HEAD:date approach, let me know how it works...)

It should work fine... but if you do that, specify an explicit date on
both.  It makes it much simpler to do the next merge.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: branching

[Keith Seitz]

On Thu, 19 Sep 2002, Kevin Buettner wrote:

> Maybe I'm being naive, but why can't you just checkout your branch,
> and then do:
> 
>     cvs update -j HEAD

Because CVS will continue to try to merge all changes into the branch 
from the time the branch was created, and you'll get tons of conflicts for 
a bunch of changes that were already merged. When you tag the mainline and 
use the two "-j" options telling CVS to merge from point A to point B, it 
only merges the new changes.

You can see this, for example, by checking out a branch and doing an 
update of a single file, once with just "-j HEAD" and once with "-j OLD -j 
NEW". For example, on my interpreter branch, valops.c was taken from 
version 1.59. When I do "cvs -q update -j HEAD" on this file, it says 
"Merging differences between 1.59 and 1.75 into valops.c". Well, I've 
already merged through version 1.69 previously, and now there are 
conflicts in the file. But when I use "-j OLD" "-j NEW", it merges only 
between 1.69 and 1.75 with no conflicts.

FWIW, David, your procedure is exactly the procedure that I've been using 
in my interpreter branch.

Keith

Re: branching

[Kevin Buettner]

On Sep 19,  1:09pm, Keith Seitz wrote:

> FWIW, David, your procedure is exactly the procedure that I've been using 
> in my interpreter branch.

Do you create a new tag for each merge?

Do you remove old tags that are no longer useful?

(Tags are cheap, but if there are enough of them, there is a definite
cost.)

Kevin

Re: branching

[Keith Seitz]

On Thu, 19 Sep 2002, Kevin Buettner wrote:

> Do you create a new tag for each merge?

Yes:
        kseitz_interps-20020829-merge   (revision: 1.69)
        kseitz_interps-20020809-merge   (revision: 1.66)
        kseitz_interps-20020722-merge   (revision: 1.65)
        kseitz_interps-20020619-merge   (revision: 1.61)
        kseitz_interps-20020528-branch  (branch: 1.59.4)
        kseitz_interps-20020528-branchpoint     (revision: 1.59)

> Do you remove old tags that are no longer useful?

Can this be done? I've never heard of anyone removing a tag. Hmm, indeed:

$ cvs rtag --help
[snip]
        -d      Delete the given tag.
[snip]

Wow. I guess I should get rid of the older tags (or use the -F option to 
move a tag).

Keith

Re: branching

[Daniel Berlin]

On Thu, 19 Sep 2002, Keith Seitz wrote:

> On Thu, 19 Sep 2002, Kevin Buettner wrote:
> 
> > Do you create a new tag for each merge?
> 
> Yes:
>         kseitz_interps-20020829-merge   (revision: 1.69)
>         kseitz_interps-20020809-merge   (revision: 1.66)
>         kseitz_interps-20020722-merge   (revision: 1.65)
>         kseitz_interps-20020619-merge   (revision: 1.61)
>         kseitz_interps-20020528-branch  (branch: 1.59.4)
>         kseitz_interps-20020528-branchpoint     (revision: 1.59)
> 
> > Do you remove old tags that are no longer useful?
> 
> Can this be done? I've never heard of anyone removing a tag. Hmm, indeed:
> 
> $ cvs rtag --help
> [snip]
>         -d      Delete the given tag.
> [snip]
> 
> Wow. I guess I should get rid of the older tags (or use the -F option to 
> move a tag).

In fact, if you really want to be advanced, and not deal with the 
slowdown on merged files that haven't been modified by you on the branch, 
but have been on the merge (This is hard to explain. If you merge from 
the head, and commit the result, it makes a new revision in the file, 
even if you haven't made changes on the branch. This eventually makes 
accessing the branch *quite* slow), you can just move the branch tags on 
the files you haven't modified on the branch, so that they refer to the 
new mainline revision.

Sounds more difficult complex than it is.

> > 
Keith > > 
> 

Re: branching

[Andrew Cagney]

> 
> In fact, if you really want to be advanced, and not deal with the 
> slowdown on merged files that haven't been modified by you on the branch, 
> but have been on the merge (This is hard to explain. If you merge from 
> the head, and commit the result, it makes a new revision in the file, 
> even if you haven't made changes on the branch. This eventually makes 
> accessing the branch *quite* slow), you can just move the branch tags on 
> the files you haven't modified on the branch, so that they refer to the 
> new mainline revision.
> 
> Sounds more difficult complex than it is.

You don't happen to have a script?  (Yes, for long lived branches things 
do start to get slow).  The other option is to fix CVS I guess.

Andrew

Re: branching

[Daniel Berlin]

On Friday, September 20, 2002, at 08:18  PM, Andrew Cagney wrote:

>> In fact, if you really want to be advanced, and not deal with the 
>> slowdown on merged files that haven't been modified by you on the 
>> branch, but have been on the merge (This is hard to explain. If you 
>> merge from the head, and commit the result, it makes a new revision 
>> in the file, even if you haven't made changes on the branch. This 
>> eventually makes accessing the branch *quite* slow), you can just 
>> move the branch tags on the files you haven't modified on the branch, 
>> so that they refer to the new mainline revision.
>> Sounds more difficult complex than it is.
>
> You don't happen to have a script?  (Yes, for long lived branches 
> things do start to get slow).  The other option is to fix CVS I guess.

cvslines can do it (http://cvslines.sourceforge.net).
Looking at the perl, it does it like so:

sub branchtag
{
   my ($file, $spec, $rev) = @_;

   print TTYO "$Myname: set branch tag \"$spec\" to revision $rev...\n";

   &do_system("cvs tag -F -r $rev -b $spec $file");
}


....
   print TTYO "$Myname: first, spoof cvs with a branch tag update...\n";
       &branchtag($file, $branchtag, $rootrev);
       print TTYO "$Myname: next, spoof the cvs up-to-date check...\n";
       &do_system("cvs update $file"); # required for inane 
up-to-date-check

>

> Andrew
>
>

Re: branching

[David Carlton]

On Thu, 19 Sep 2002 13:09:56 -0700 (PDT), Keith Seitz <keiths@redhat.com> said:

> FWIW, David, your procedure is exactly the procedure that I've been
> using in my interpreter branch.

Great, glad to hear I'm on track.  Could you tell me exactly what you
type to create the merge tags on the mainline and to update your
branch to reflect the changes between two mainline merge tags?  (And
whatever words of wisdom you have on the subject of, when you use cvs
rtag to create a tag, what branch(es?) that tags applies to, would be
greatly appreciated.)

I like your -merge nomenclature better than my -tag nomenclature, too:
everything that I do with rtag is a tag, after all, so -tag isn't very
meaningful...

And, given that I'm probably temperamentally suited to relatively
frequent merges, I'll want to take Kevin's advice and delete merge
tags that I haven't used for a while.

David Carlton
carlton@math.stanford.edu

Re: branching

[Keith Seitz]

On 19 Sep 2002, David Carlton wrote:

> Great, glad to hear I'm on track.  Could you tell me exactly what you
> type to create the merge tags on the mainline and to update your
> branch to reflect the changes between two mainline merge tags?  (And
> whatever words of wisdom you have on the subject of, when you use cvs
> rtag to create a tag, what branch(es?) that tags applies to, would be
> greatly appreciated.)

Sure. To create the symbol tag in mainline (I use rtag, since it will tag 
the repository copy, not any local copy):
$ cvs rtag kseitz_interps-DATE-merge gdb+dejagnu

Then to apply the tag to my branch, I "cd" into my branch sources
$ cd my-branch/src
$ cvs -q update -j kseitz_interps-LASTDATE-merge  \
  -j kseitz_interps-DATE-merge gdb+dejagnu

Finally resolve any conflicts and "cvs ci". 
 
> And, given that I'm probably temperamentally suited to relatively
> frequent merges, I'll want to take Kevin's advice and delete merge
> tags that I haven't used for a while.

Hmm, yeah, I guess I should do that, too.

Keith

Re: branching

[David Carlton]

On Thu, 19 Sep 2002 14:55:34 -0700 (PDT), Keith Seitz <keiths@redhat.com> said:

> To create the symbol tag in mainline (I use rtag, since it will tag 
> the repository copy, not any local copy):
> $ cvs rtag kseitz_interps-DATE-merge gdb+dejagnu

> Then to apply the tag to my branch, I "cd" into my branch sources
> $ cd my-branch/src
> $ cvs -q update -j kseitz_interps-LASTDATE-merge  \
>   -j kseitz_interps-DATE-merge gdb+dejagnu

> Finally resolve any conflicts and "cvs ci". 
 
Thanks.  I still don't understand rtag completely, but at least I know
what to type now...

David Carlton
carlton@math.stanford.edu