From: Russell Shaw <rjshaw@netspace.net.au>
To: Paul Schlie <schlie@comcast.net>
Cc: gdb@sources.redhat.com
Subject: Re: Branching
Date: Sun, 13 Feb 2005 11:14:00 -0000 [thread overview]
Message-ID: <420E9CBB.30003@netspace.net.au> (raw)
In-Reply-To: <BE33C9C3.9096%schlie@comcast.net>
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?
next prev parent reply other threads:[~2005-02-13 0:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-13 0:10 Branching Paul Schlie
2005-02-13 11:14 ` Russell Shaw [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-02-12 4:24 Branching Russell Shaw
[not found] <ro1fzw9h8r2.fsf@jackfruit.Stanford.EDU>
[not found] ` <20020917143553.GA28408@nevyn.them.org>
[not found] ` <ro1k7lkfr5d.fsf@jackfruit.Stanford.EDU>
[not found] ` <20020917174928.GA23058@nevyn.them.org>
[not found] ` <ro165x4fotl.fsf@jackfruit.Stanford.EDU>
[not found] ` <3D87815A.4010807@ges.redhat.com>
2002-09-19 12:12 ` branching David Carlton
2002-09-19 12:30 ` branching Kevin Buettner
2002-09-19 12:35 ` branching David Carlton
2002-09-19 13:07 ` branching Kevin Buettner
2002-09-19 13:12 ` branching Daniel Jacobowitz
2002-09-19 13:07 ` branching Keith Seitz
2002-09-19 13:11 ` branching Kevin Buettner
2002-09-19 13:19 ` branching Keith Seitz
2002-09-19 22:29 ` branching Daniel Berlin
2002-09-20 17:18 ` branching Andrew Cagney
2002-09-20 17:45 ` branching Daniel Berlin
2002-09-19 13:45 ` branching David Carlton
2002-09-19 14:52 ` branching Keith Seitz
2002-09-19 15:10 ` branching David Carlton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=420E9CBB.30003@netspace.net.au \
--to=rjshaw@netspace.net.au \
--cc=gdb@sources.redhat.com \
--cc=schlie@comcast.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox