Binutils 2.18 prep

Binutils 2.18 prep

[Daniel Jacobowitz]

Hello all,

According to the informal schedule I've been following, binutils 2.18
should be coming up soon.  I have a collection of flagged messages to
go back to before I let another release out the door, but I definitely
don't claim to track everything.  If you have any recently committed
projects (or likely to be committed soon) that should have a little
more time to settle, please let me know.

I expect to create the branch within a couple of weeks.  I'd like to
keep the branch-to-release interval fairly short; I've been using
better revision control systems than CVS lately, and they've left me
very bitter about having to merge patches to a CVS branch.  Volunteers
to find a workable way to use SVN for src instead are highly welcomed
as far as I'm concerned.

-- 
Daniel Jacobowitz
CodeSourcery

SVN for src (was Re: Binutils 2.18 prep)

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> I expect to create the branch within a couple of weeks.  I'd like to
> keep the branch-to-release interval fairly short; I've been using
> better revision control systems than CVS lately, and they've left me
> very bitter about having to merge patches to a CVS branch.  Volunteers
> to find a workable way to use SVN for src instead are highly welcomed
> as far as I'm concerned.

My understanding is that the problem is the lack of Subversion support 
for something like CVS modules.

I have been thinking about this problem recently. Obviously the best 
solution is native support from Subversion, but in it's absence I have 
come up with an alternative. Sorry if I've just re-invented a well known 
solution, but here goes:

We create an Subversion directory containing all the top-level files 
(configure etc.), but with all the subdirectories (gas, gdb etc.) 
present but *empty*. We then provide a script that does 'svn switch' on 
each directory required for a given 'module'. This is the inverse of the 
svn://gcc.gnu.org/svn/gcc/emptydir idea (see 
http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage").

The repository might look like:

trunk/
   src/
     configure
     Makefile.in
     ...
     binutils/
     gas/
     gdb/
     ...
     switch-modules.sh
   modules/
     binutils/
       ar.c
       ...
     gas/
       as.c
       ...
     gdb/
       gdb.c
       ...
     ...

So you have a two-step checkout procedure:

   svn checkout svn:://sourceware.org/svn/trunk/src
   cd src
   ./switch-modules.sh binutils

The script would then do:

   svn switch svn://sourceware.org/svn/trunk/modules/binutils binutils
   svn switch svn://sourceware.org/svn/trunk/modules/gas gas
   svn switch svn://sourceware.org/svn/trunk/modules/include include
   ...

This is not an ideal solution - it requires two steps, 'svn status' will 
always list all the switches, and it does not provide fine grained 
control over the contents of each directory. However, it does solve the 
problem of enormous working trees.

Just a thought

Andrew

Re: SVN for src (was Re: Binutils 2.18 prep)

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

On Thu, 22 Mar 2007 10:06:41 +0000
Andrew STUBBS <andrew.stubbs@st.com> wrote:
> This is not an ideal solution - it requires two steps, 'svn status'
> will always list all the switches,

This should be solvable by using svn:externals [1]

[1] http://svnbook.red-bean.com/en/1.1/ch07s04.html
-- 
Diego "Flameeyes" Pettenò
http://farragut.flameeyes.is-a-geek.org/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: SVN for src (was Re: Binutils 2.18 prep)

[Andrew STUBBS]

Diego 'Flameeyes' Pettenò wrote:
> On Thu, 22 Mar 2007 10:06:41 +0000
> Andrew STUBBS <andrew.stubbs@st.com> wrote:
>> This is not an ideal solution - it requires two steps, 'svn status'
>> will always list all the switches,
> 
> This should be solvable by using svn:externals [1]
> 
> [1] http://svnbook.red-bean.com/en/1.1/ch07s04.html

I think you misunderstand externals.

1. External directories are automatically checked out when you check out 
the parent. My suggestion is specifically NOT to check out ALL 
subdirectories.

2. 'svn status' lists externals, much as it does switches, so no win there.

3. You can't commit the whole tree at once, if part of it is external, 
unlike with switched directories (from the same repository), where it is 
totally transparent.

Andrew

Re: SVN for src (was Re: Binutils 2.18 prep)

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

On Thu, 22 Mar 2007 11:05:57 +0000
Andrew STUBBS <andrew.stubbs@st.com> wrote:
> I think you misunderstand externals.
I think I rather misunderstood you, and tried to address different
particular problems that you were trying to address.

> 1. External directories are automatically checked out when you check
> out the parent. My suggestion is specifically NOT to check out ALL 
> subdirectories.
Okay, then for that, externals is mostly useless.. although you can
still use -n to checkout non-recursively the main directory and then
checkout what you actually need (this is what I actually do for KDE and
a few other cases).
As I said, different scopes on the suggestions, I was suggesting a way
to avoid the extra script, you were suggesting a way to avoid the whole
checkout.

> 3. You can't commit the whole tree at once, if part of it is
> external, unlike with switched directories (from the same
> repository), where it is totally transparent.
And this is a point well taken, I didn't think at all of this, thanks
for the insight, it's something I'll have to think about next time I
set up a repository.

-- 
Diego "Flameeyes" Pettenò
http://farragut.flameeyes.is-a-geek.org/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: SVN for src (was Re: Binutils 2.18 prep)

[Paul Brook]

> We create an Subversion directory containing all the top-level files
> (configure etc.), but with all the subdirectories (gas, gdb etc.)
> present but *empty*. We then provide a script that does 'svn switch' on
> each directory required for a given 'module'. This is the inverse of the
> svn://gcc.gnu.org/svn/gcc/emptydir idea (see
> http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage").

How does this work with branches and tagging? Do we have to manually (or using 
a script) branch+tag every subdirectory?

Paul

Re: SVN for src (was Re: Binutils 2.18 prep)

[Bob Rossi]

On Thu, Mar 22, 2007 at 10:06:41AM +0000, Andrew STUBBS wrote:
> Daniel Jacobowitz wrote:
> >I expect to create the branch within a couple of weeks.  I'd like to
> >keep the branch-to-release interval fairly short; I've been using
> >better revision control systems than CVS lately, and they've left me
> >very bitter about having to merge patches to a CVS branch.  Volunteers
> >to find a workable way to use SVN for src instead are highly welcomed
> >as far as I'm concerned.
> 
> My understanding is that the problem is the lack of Subversion support 
> for something like CVS modules.

It seems to me like a high profile project like this might be able to
get the subversion guys to add a feature or two in order to make svn
more usable in large, real world projects?

Bob Rossi

Re: SVN for src (was Re: Binutils 2.18 prep)

[Daniel Jacobowitz]

On Thu, Mar 22, 2007 at 10:11:22AM -0400, Bob Rossi wrote:
> On Thu, Mar 22, 2007 at 10:06:41AM +0000, Andrew STUBBS wrote:
> > Daniel Jacobowitz wrote:
> > >I expect to create the branch within a couple of weeks.  I'd like to
> > >keep the branch-to-release interval fairly short; I've been using
> > >better revision control systems than CVS lately, and they've left me
> > >very bitter about having to merge patches to a CVS branch.  Volunteers
> > >to find a workable way to use SVN for src instead are highly welcomed
> > >as far as I'm concerned.
> > 
> > My understanding is that the problem is the lack of Subversion support 
> > for something like CVS modules.
> 
> It seems to me like a high profile project like this might be able to
> get the subversion guys to add a feature or two in order to make svn
> more usable in large, real world projects?

I think the feature we need is even on the drawing board already for
an unspecified future release - an equivalent to svk's "views".  Dan,
am I just making that up?

-- 
Daniel Jacobowitz
CodeSourcery

Re: SVN for src (was Re: Binutils 2.18 prep)

[Andrew STUBBS]

Paul Brook wrote:
>> We create an Subversion directory containing all the top-level files
>> (configure etc.), but with all the subdirectories (gas, gdb etc.)
>> present but *empty*. We then provide a script that does 'svn switch' on
>> each directory required for a given 'module'. This is the inverse of the
>> svn://gcc.gnu.org/svn/gcc/emptydir idea (see
>> http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage").
> 
> How does this work with branches and tagging? Do we have to manually (or using 
> a script) branch+tag every subdirectory?

If you branch/tag the whole trunk then there's no problem.

E.g.

tags/
   2.18/
     src/
     modules/
trunk/
   src/
   modules/

Of course, the script to do the switching has to be able to detect what 
branch to use. However, the most portable approach would be to look for 
the modules relative to the URL obtained using 'svn info'. That would 
work even when the URL changes or the repository is mirrored.

Andrew

Re: SVN for src (was Re: Binutils 2.18 prep)

[Joseph S. Myers]

On Thu, 22 Mar 2007, Paul Brook wrote:

> > We create an Subversion directory containing all the top-level files
> > (configure etc.), but with all the subdirectories (gas, gdb etc.)
> > present but *empty*. We then provide a script that does 'svn switch' on
> > each directory required for a given 'module'. This is the inverse of the
> > svn://gcc.gnu.org/svn/gcc/emptydir idea (see
> > http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage").
> 
> How does this work with branches and tagging? Do we have to manually (or using 
> a script) branch+tag every subdirectory?

You can copy a checkout to a URI.  I know that works for modified and 
mixed-revision working copies; if it works for switched working copies, 
you'd get a branch or tag replicating that copy (so with binutils only if 
it was a checkout switched to be a binutils-only checkout, for example).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: SVN for src (was Re: Binutils 2.18 prep)

[Daniel Jacobowitz]

On Thu, Mar 22, 2007 at 10:06:41AM +0000, Andrew STUBBS wrote:
> We create an Subversion directory containing all the top-level files (configure 
> etc.), but with all the subdirectories (gas, gdb etc.) present but *empty*. We 
> then provide a script that does 'svn switch' on each directory required for a 
> given 'module'. This is the inverse of the svn://gcc.gnu.org/svn/gcc/emptydir 
> idea (see http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage").

You know, I think we can do this even without having to butcher the
layout of the repository.  Check out a directory containing just the
script, and have it use "svn switch -N" at the end to pick up the top
level files.

I'm going to experiment.  I have a handy repository to work with :-)
(We import CVS snapshots into svn.)

-- 
Daniel Jacobowitz
CodeSourcery

Re: SVN for src (was Re: Binutils 2.18 prep)

[Daniel Jacobowitz]

On Thu, Mar 22, 2007 at 11:00:18AM -0400, Daniel Jacobowitz wrote:
> On Thu, Mar 22, 2007 at 10:06:41AM +0000, Andrew STUBBS wrote:
> > We create an Subversion directory containing all the top-level files (configure 
> > etc.), but with all the subdirectories (gas, gdb etc.) present but *empty*. We 
> > then provide a script that does 'svn switch' on each directory required for a 
> > given 'module'. This is the inverse of the svn://gcc.gnu.org/svn/gcc/emptydir 
> > idea (see http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage").
> 
> You know, I think we can do this even without having to butcher the
> layout of the repository.  Check out a directory containing just the
> script, and have it use "svn switch -N" at the end to pick up the top
> level files.
> 
> I'm going to experiment.  I have a handy repository to work with :-)
> (We import CVS snapshots into svn.)

Here's what I've got so far.  These are all just my observations, so
my assertions about how Subversion works may be bogus.

Suppose we leave the repository layout exactly the same as it is now.

Check out the trunk using "svn co -N" for non-recursive.  You will get
only the trunk - no subdirectories.  Unlike in CVS they will never
spontaneously appear after this point; "svn up" will only create new
directories when it updates through a revision in the repository that
created the directory.  Otherwise, it appears to assume that the
directory is deliberately missing if it is not mentioned in
.svn/entries.  However, an explicit "svn up gdb" in this case will
work!

So, we can put a script in the top level to check out a module.  If
you check out the repository URL you'll get all of src; if you check
out using -N and run the script with appropriate argument, you'll get
only binutils.  Or only GDB, et cetera.  We'll probably need to
maintain a list of subdirectories for anything where directories are
omitted from some modules; that's top level, gdb and gdb/testsuite/
(for Insight), and cgen.  It'll be a hassle but not a huge hassle.

Not everything is rosy.  "svn cp . $repo/branches/new-branch" will
copy the omitted directories, which is peculiar, so we would either
need people branching to get a hypothetical svn which didn't do that
or use a script to create branches.  But it's much less messy than
using externals would be.

Any thoughts?  Is this really workable?

-- 
Daniel Jacobowitz
CodeSourcery

Re: SVN for src (was Re: Binutils 2.18 prep)

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> On Thu, Mar 22, 2007 at 10:06:41AM +0000, Andrew STUBBS wrote:
>> We create an Subversion directory containing all the top-level files (configure 
>> etc.), but with all the subdirectories (gas, gdb etc.) present but *empty*. We 
>> then provide a script that does 'svn switch' on each directory required for a 
>> given 'module'. This is the inverse of the svn://gcc.gnu.org/svn/gcc/emptydir 
>> idea (see http://gcc.gnu.org/wiki/SvnSetup "Optimize disk usage").
> 
> You know, I think we can do this even without having to butcher the
> layout of the repository.  Check out a directory containing just the
> script, and have it use "svn switch -N" at the end to pick up the top
> level files.
> 
> I'm going to experiment.  I have a handy repository to work with :-)
> (We import CVS snapshots into svn.)

Magic, it works!

I did originally think about doing 'svn co -N src', but that makes it 
impossible to get at the subdirectories at all (another checkout works, 
but then you can't check in properly).

I hadn't though of pulling in the root via switch. Nice idea.

So we would have:

   svn co svn://sourceware.org/svn/trunk/modular-checkout src
   cd src
   ./checkout binutils

which would then do:

   svn switch svn://sourceware.org/svn/trunk/src/binutils binutils
   svn switch svn://sourceware.org/svn/trunk/src/gas gas
   ...
   svn switch -N svn://sourceware.org/svn/trunk/src .

where the last line switches in the top level files, and switches out 
the checkout script itself.

Anybody wanting to checkout *everything* still can, without jumping 
through hoops!

I suppose that, given the -N switch, it is even possible to selectively 
choose subdirectories (such as include/elf), as long as the empty 
version already exists, thus:

   svn switch -N svn://sourceware.org/svn/trunk/src/include include
   svn switch svn://sourceware.org/svn/trunk/src/include/elf \
		include/elf

I can't think of any way to select individual files.

Andrew

Re: SVN for src (was Re: Binutils 2.18 prep)

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> Check out the trunk using "svn co -N" for non-recursive.  You will get
> only the trunk - no subdirectories.  Unlike in CVS they will never
> spontaneously appear after this point; "svn up" will only create new
> directories when it updates through a revision in the repository that
> created the directory.  Otherwise, it appears to assume that the
> directory is deliberately missing if it is not mentioned in
> .svn/entries.  However, an explicit "svn up gdb" in this case will
> work!

Try a commit. I'm fairly sure that any subsequent check-outs within the 
working-copy are separate - you can't check-in changes to different 
directories simultaneously.

It will be perfectly adequate for building and diffing, of course.

> Not everything is rosy.  "svn cp . $repo/branches/new-branch" will
> copy the omitted directories, which is peculiar, so we would either
> need people branching to get a hypothetical svn which didn't do that
> or use a script to create branches.  But it's much less messy than
> using externals would be.

What's wrong with creating a branch that contains everything? This is 
the natural way to work with svn - copies are not expensive. One can 
then check out modules on the branch in the same way as the trunk.

This does raise an interesting point: it would not be trivial to 'svn 
switch' to different branches. Not impossible, but not trivial.

Andrew

Re: SVN for src (was Re: Binutils 2.18 prep)

[DJ Delorie]

Daniel Jacobowitz <drow@false.org> writes:
> You know, I think we can do this even without having to butcher the
> layout of the repository.  Check out a directory containing just the
> script, and have it use "svn switch -N" at the end to pick up the top
> level files.

The thing to watch out for is an svn update to a different revision,
which has a tendency to re-populate all the missing directories.  I've
gotten bitten by this a few times trying to track down gcc bugs by
date; it kept pulling in the ada/java sources and I kept trying to
delete them.

Re: SVN for src (was Re: Binutils 2.18 prep)

[Andrew STUBBS]

DJ Delorie wrote:
> Daniel Jacobowitz <drow@false.org> writes:
>> You know, I think we can do this even without having to butcher the
>> layout of the repository.  Check out a directory containing just the
>> script, and have it use "svn switch -N" at the end to pick up the top
>> level files.
> 
> The thing to watch out for is an svn update to a different revision,
> which has a tendency to re-populate all the missing directories.  I've
> gotten bitten by this a few times trying to track down gcc bugs by
> date; it kept pulling in the ada/java sources and I kept trying to
> delete them.
> 

Even when you followed the "optimize disk usage" instructions at 
http://gcc.gnu.org/wiki/SvnSetup ???

Andrew

Re: SVN for src (was Re: Binutils 2.18 prep)

[DJ Delorie]

> Even when you followed the "optimize disk usage" instructions at 
> http://gcc.gnu.org/wiki/SvnSetup ???

Yes.  Updating to a specific date seems to undo the svn switch.

Re: SVN for src (was Re: Binutils 2.18 prep)

[Andrew STUBBS]

DJ Delorie wrote:
>> Even when you followed the "optimize disk usage" instructions at 
>> http://gcc.gnu.org/wiki/SvnSetup ???
> 
> Yes.  Updating to a specific date seems to undo the svn switch.

But a regular update (to head) works as expected? Inconvenient. The 
manual does suggest that update is just a special case of switch. I 
guess updating to a specific date isn't so special - it's exactly switch 
to the date.

I suppose someone needs to report that one to the SVN guys, if they 
don't already know.

Andrew

Re: SVN for src (was Re: Binutils 2.18 prep)

[Daniel Jacobowitz]

On Thu, Mar 22, 2007 at 12:11:15PM -0400, DJ Delorie wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> > You know, I think we can do this even without having to butcher the
> > layout of the repository.  Check out a directory containing just the
> > script, and have it use "svn switch -N" at the end to pick up the top
> > level files.
> 
> The thing to watch out for is an svn update to a different revision,
> which has a tendency to re-populate all the missing directories.  I've
> gotten bitten by this a few times trying to track down gcc bugs by
> date; it kept pulling in the ada/java sources and I kept trying to
> delete them.

Can you be more specific?  I tried to reproduce this, to find problems
with my tentative plan, but I couldn't.  It might be disrupted if you
use -r before and after the creation of a directory, but I think only
for that directory.

-- 
Daniel Jacobowitz
CodeSourcery

Re: SVN for src (was Re: Binutils 2.18 prep)

[Daniel Jacobowitz]

On Thu, Mar 22, 2007 at 03:51:45PM +0000, Andrew STUBBS wrote:
> Daniel Jacobowitz wrote:
> >Check out the trunk using "svn co -N" for non-recursive.  You will get
> >only the trunk - no subdirectories.  Unlike in CVS they will never
> >spontaneously appear after this point; "svn up" will only create new
> >directories when it updates through a revision in the repository that
> >created the directory.  Otherwise, it appears to assume that the
> >directory is deliberately missing if it is not mentioned in
> >.svn/entries.  However, an explicit "svn up gdb" in this case will
> >work!

> Try a commit. I'm fairly sure that any subsequent check-outs within the 
> working-copy are separate - you can't check-in changes to different directories 
> simultaneously.

> It will be perfectly adequate for building and diffing, of course.

"svn co" in a checkout creates something completely separate; "svn up"
as I described does not.  So commiting worked.  But checking out
libiberty and libiberty/config, then committing to libiberty testsuite
from another tree, then svn updating the first tree failed with
'Directory "testsuite" is missing'.  A second svn up pulled in the
directory.

I guess that means it's not going to work out this way.  Drat.

-- 
Daniel Jacobowitz
CodeSourcery

Re: SVN for src (was Re: Binutils 2.18 prep)

[Daniel Jacobowitz]

On Mon, Mar 26, 2007 at 10:45:14AM -0400, Daniel Jacobowitz wrote:
> On Thu, Mar 22, 2007 at 12:11:15PM -0400, DJ Delorie wrote:
> > Daniel Jacobowitz <drow@false.org> writes:
> > > You know, I think we can do this even without having to butcher the
> > > layout of the repository.  Check out a directory containing just the
> > > script, and have it use "svn switch -N" at the end to pick up the top
> > > level files.
> > 
> > The thing to watch out for is an svn update to a different revision,
> > which has a tendency to re-populate all the missing directories.  I've
> > gotten bitten by this a few times trying to track down gcc bugs by
> > date; it kept pulling in the ada/java sources and I kept trying to
> > delete them.
> 
> Can you be more specific?  I tried to reproduce this, to find problems
> with my tentative plan, but I couldn't.  It might be disrupted if you
> use -r before and after the creation of a directory, but I think only
> for that directory.

Never mind.  I see now.

% svn switch file:///space/codesourcery/local-svk/local/empty testsuite
% svn up
% svn up -r330
D    testsuite
...
svn: Directory 'testsuite' is missing
% svn up -r330
A    testsuite
A    testsuite/test-pexecute.c
...

Whoops.

-- 
Daniel Jacobowitz
CodeSourcery

Re: SVN for src (was Re: Binutils 2.18 prep)

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> "svn co" in a checkout creates something completely separate; "svn up"
> as I described does not.  So commiting worked.  But checking out
> libiberty and libiberty/config, then committing to libiberty testsuite
> from another tree, then svn updating the first tree failed with
> 'Directory "testsuite" is missing'.  A second svn up pulled in the
> directory.
> 
> I guess that means it's not going to work out this way.  Drat.

I thought I tested "svn up <dir>" and it didn't work??? Maybe it's an 
svn version thing, or maybe my memory is broken.

Anyway, when I try it now it does work, and I have reproduced your issue.

That gives 3 issues with this approach:
   1. "svn up -r"
   2. "svn switch"
   3. "svn up" when something has changed in a "missing" directory.

I have done a few experiments, and I believe this can all be fixed with 
the same set of -N options that were used in the initial "checkout".

E.g. If you checkout with:

   svn co svn:...src -N
   svn up src/libiberty -N
   svn up src/config

then you must update with:

   svn up src -N
   svn up src/libiberty -N
   svn up src/config

and switch to branch/update to revision with:

   svn up -r$rev src -N
   svn up -r$rev src/libiberty -N
   svn up -r$rev src/config

I think the script to do the checkout can be used for all these tasks 
and can remove all these issues. That is, provided that the user never 
does anything else 'creative'. If the user does their own 
updates/switches then the script might to something undesirable.

There is also one other *big* issue, although it may not seem like it 
for CVS users. Any directory checked out or updated with -N will cause 
newly created subdirectories to be omitted from checkouts, or 
conversely, newly deleted directories will be left in (and these effects 
will be reversed when the current revision is moved backwards). A simple 
solution to this problem would be to limit module selection to top-level 
directories only (and then do a full recursive update for each). A more 
complex solution would be to have the script recurse over the whole tree 
and "deal" with each directory (note that "svn ls" always lists 
directories that are "missing"). The script would have to either update 
itself first, in order to make sure the set of directories is correct, 
or else the module information would have to be encoded as svn 
properties on each directory, and thus automatically updated.

All in all, I believe that, even before subversion introduces proper 
support for something module-like, it is possible to switch to 
subversion, provided that users are prepared to be disciplined in their 
use of checkout and update. There will be no need to modify the 
structure of the repository (so people who checkout the whole world 
still can), and when svn modules are implemented, there will be no 
painful transition (of our doing).

Andrew

Re: SVN for src (was Re: Binutils 2.18 prep)

[Daniel Jacobowitz]

On Mon, Mar 26, 2007 at 05:16:17PM +0100, Andrew STUBBS wrote:
> All in all, I believe that, even before subversion introduces proper support 
> for something module-like, it is possible to switch to subversion, provided 
> that users are prepared to be disciplined in their use of checkout and update. 
> There will be no need to modify the structure of the repository (so people who 
> checkout the whole world still can), and when svn modules are implemented, 
> there will be no painful transition (of our doing).

Anyway, let's wait.  Jim Blandy pointed out to me that most of what we
need will be in Subversion 1.5 ("sparse directories").  It may be
awkward, especially for gdb/testsuite/gdb.gdbtk, but we'll work
something out.

-- 
Daniel Jacobowitz
CodeSourcery

Re: SVN for src (was Re: Binutils 2.18 prep)

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> On Mon, Mar 26, 2007 at 05:16:17PM +0100, Andrew STUBBS wrote:
>> All in all, I believe that, even before subversion introduces proper support 
>> for something module-like, it is possible to switch to subversion, provided 
>> that users are prepared to be disciplined in their use of checkout and update. 
>> There will be no need to modify the structure of the repository (so people who 
>> checkout the whole world still can), and when svn modules are implemented, 
>> there will be no painful transition (of our doing).
> 
> Anyway, let's wait.  Jim Blandy pointed out to me that most of what we
> need will be in Subversion 1.5 ("sparse directories").  It may be
> awkward, especially for gdb/testsuite/gdb.gdbtk, but we'll work
> something out.

I had not heard of sparse directories, but then I don't follow SVN 
development. I'm not sure where the proper documentation of these 
features might be, but I found this: 
http://svn.collab.net/viewvc/svn/trunk/notes/sparse-directories.txt?view=markup

It would appear that the new feature is exactly what we were discussing, 
except with the update/switch issues resolved. We would still need a 
checkout script to implement the `modules', but it would not be 
necessary to use it for switch or update. Indeed it would also appear to 
be no more powerful than the accidental-feature abuse we were talking 
about - i.e. you can choose your directories, but you can't choose your 
files.

I do not see a big issue with gdb.gdbtk, or indeed the various bits of 
include that are not distributed with some projects. Care would have to 
be taken that updates don't ignore new directories, but that's just a 
question of ensuring that each directory has the proper depth parameter set.

I would suggest now that the real problem is how to convert CVS to SVN. 
I haven't even got a clue how that could be done. The GCC project 
managed it, but I imagine that it will take a CVS expert some time to 
get that mammoth process completed.

Andrew

Re: SVN for src (was Re: Binutils 2.18 prep)

[Daniel Jacobowitz]

On Wed, Apr 11, 2007 at 11:22:23AM +0100, Andrew STUBBS wrote:
> I would suggest now that the real problem is how to convert CVS to SVN. I 
> haven't even got a clue how that could be done. The GCC project managed it, but 
> I imagine that it will take a CVS expert some time to get that mammoth process 
> completed.

Actually, that part is quite simple.  cvs2svn is a very good utility
:-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: SVN for src (was Re: Binutils 2.18 prep)

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> On Wed, Apr 11, 2007 at 11:22:23AM +0100, Andrew STUBBS
 Daniel> wrote:
 >> I would suggest now that the real problem is how to convert CVS to
 >> SVN. I haven't even got a clue how that could be done. The GCC
 >> project managed it, but I imagine that it will take a CVS expert
 >> some time to get that mammoth process completed.

 Daniel> Actually, that part is quite simple.  cvs2svn is a very good
 Daniel> utility :-)

Absolutely.  I used it a bit over a year ago on a large project, and
of course the GCC project did likewise.  It was entirely painless.
Just run it and admire the result.

     paul

Re: SVN for src (was Re: Binutils 2.18 prep)

[Ian Lance Taylor]

Andrew STUBBS <andrew.stubbs@st.com> writes:

> I would suggest now that the real problem is how to convert CVS to
> SVN. I haven't even got a clue how that could be done. The GCC project
> managed it, but I imagine that it will take a CVS expert some time to
> get that mammoth process completed.

The gcc conversion, which was done by Daniel Berlin, had two
interesting parts.  The first was that the gcc repository was very
large with a lot of revisions, and the conversion process took more
than two days on a powerful system.  The second was that we wanted to
include older gcc version data from the FSF RCS files which were not
in the CVS repository.  I wrote some hacks to include the RCS revision
history in a copy of the CVS repository before the revision.

I would very much like to do the same thing with the old Cygnus
binutils repository at Red Hat.  The problem is the customer
confidential code in the Cygnus repository.  However, we would only be
interested in the Cygnus repository up to the point when the
sourceware repository was created, in May 1999.  When I was at Cygnus
we always wrote our contracts to say that confidential information
could be released when the customer specified or after three years had
passed.  So, unless they changed that policy after I left in 1998, an
eight year lag should be legally OK.

Nick, could you see if you can get permission to release the
binutils/gdb/newlib/cygwin revision history from the Cygnus repository
up through May, 1999?  If you can, I'll work on incorporating that
revision history into the sourceware repository.

I think that would be very convenient for future development.

Ian

Re: SVN for src (was Re: Binutils 2.18 prep)

[Daniel Jacobowitz]

On Wed, Apr 11, 2007 at 07:14:34AM -0700, Ian Lance Taylor wrote:
> Nick, could you see if you can get permission to release the
> binutils/gdb/newlib/cygwin revision history from the Cygnus repository
> up through May, 1999?  If you can, I'll work on incorporating that
> revision history into the sourceware repository.
> 
> I think that would be very convenient for future development.

This hadn't even occurred to me - but it would be great to have!
The result might be a bit confusing; I believe the gcc.gnu.org
repository just began when it began, but the sourceware repository had
snapshots of previous GDB releases imported into it.  So things may
seem to appear and then disappear.

-- 
Daniel Jacobowitz
CodeSourcery

Re: SVN for src (was Re: Binutils 2.18 prep)

[Ian Lance Taylor]

Daniel Jacobowitz <drow@false.org> writes:

> On Wed, Apr 11, 2007 at 07:14:34AM -0700, Ian Lance Taylor wrote:
> > Nick, could you see if you can get permission to release the
> > binutils/gdb/newlib/cygwin revision history from the Cygnus repository
> > up through May, 1999?  If you can, I'll work on incorporating that
> > revision history into the sourceware repository.
> > 
> > I think that would be very convenient for future development.
> 
> This hadn't even occurred to me - but it would be great to have!
> The result might be a bit confusing; I believe the gcc.gnu.org
> repository just began when it began, but the sourceware repository had
> snapshots of previous GDB releases imported into it.  So things may
> seem to appear and then disappear.

We control the horizontal and the vertical.  If we get the old
binutils/gdb revision history, we can clobber the gdb snapshots when
we merge.

Ian

Re: Binutils 2.18 prep

[Daniel Jacobowitz]

On Wed, Mar 21, 2007 at 10:48:38PM -0400, Daniel Jacobowitz wrote:
> Hello all,
> 
> According to the informal schedule I've been following, binutils 2.18
> should be coming up soon.  I have a collection of flagged messages to
> go back to before I let another release out the door, but I definitely
> don't claim to track everything.  If you have any recently committed
> projects (or likely to be committed soon) that should have a little
> more time to settle, please let me know.

Hi folks,

Obviously that didn't happen.  Let's try again.  If you know of any
issues in HEAD that should not be in a stable release, please let me
know.  Otherwise, I will tentatively plan:

- Branch 6th August
- Release 27th August

-- 
Daniel Jacobowitz
CodeSourcery

Re: Binutils 2.18 prep

[H.J. Lu]

On Mon, Jul 30, 2007 at 12:51:46PM -0400, Daniel Jacobowitz wrote:
> On Wed, Mar 21, 2007 at 10:48:38PM -0400, Daniel Jacobowitz wrote:
> > Hello all,
> > 
> > According to the informal schedule I've been following, binutils 2.18
> > should be coming up soon.  I have a collection of flagged messages to
> > go back to before I let another release out the door, but I definitely
> > don't claim to track everything.  If you have any recently committed
> > projects (or likely to be committed soon) that should have a little
> > more time to settle, please let me know.
> 
> Hi folks,
> 
> Obviously that didn't happen.  Let's try again.  If you know of any
> issues in HEAD that should not be in a stable release, please let me
> know.  Otherwise, I will tentatively plan:
> 

We need to resolve:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=4781


H.J.

Re: Binutils 2.18 prep

[Jim Wilson]

On Mon, 2007-07-30 at 12:51 -0400, Daniel Jacobowitz wrote:
> Obviously that didn't happen.  Let's try again.  If you know of any
> issues in HEAD that should not be in a stable release, please let me
> know.  Otherwise, I will tentatively plan:

I've been a bit negligent with my IA-64 maintainership duties.  I have
some patches I need to review.  I'm not sure if there is anything
critical in there though.  But I've got a month to get this straightened
out, so this should be no reason to delay the branch.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: Binutils 2.18 prep

[l l]

Hi,

I wish more support for x86_64.
I am using amd64 x2 4800+ 65nm.

TIA

2007/8/2, Jim Wilson <wilson@specifix.com>:
> On Mon, 2007-07-30 at 12:51 -0400, Daniel Jacobowitz wrote:
> > Obviously that didn't happen.  Let's try again.  If you know of any
> > issues in HEAD that should not be in a stable release, please let me
> > know.  Otherwise, I will tentatively plan:
>
> I've been a bit negligent with my IA-64 maintainership duties.  I have
> some patches I need to review.  I'm not sure if there is anything
> critical in there though.  But I've got a month to get this straightened
> out, so this should be no reason to delay the branch.
> --
> Jim Wilson, GNU Tools Support, http://www.specifix.com
>
>
>

Re: Binutils 2.18 prep

[Daniel Jacobowitz]

On Mon, Jul 30, 2007 at 12:51:46PM -0400, Daniel Jacobowitz wrote:
> Hi folks,
> 
> Obviously that didn't happen.  Let's try again.  If you know of any
> issues in HEAD that should not be in a stable release, please let me
> know.  Otherwise, I will tentatively plan:
> 
> - Branch 6th August
> - Release 27th August

This time, it did happen.  I have created the new branch,
binutils-2_18-branch.  There is a snapshot from the branch in the
snapshots directory on sourceware, which I have forwarded to the
Translation Project.

As usual, for the next two weeks or so please feel free to apply
bug fixes to the branch when you apply them to HEAD.  Thanks!

-- 
Daniel Jacobowitz
CodeSourcery

Add bfin-*rtems* [was: Binutils 2.18 prep]

[Ralf Corsepius]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

On Mon, 2007-08-06 at 17:12 -0400, Daniel Jacobowitz wrote:
> On Mon, Jul 30, 2007 at 12:51:46PM -0400, Daniel Jacobowitz wrote:
> > Hi folks,

> This time, it did happen.  I have created the new branch,
> binutils-2_18-branch. 

> As usual, for the next two weeks or so please feel free to apply
> bug fixes to the branch when you apply them to HEAD.  Thanks!

I'd appreciate it, if somebody could apply the patch below to the branch
and HEAD. It's the only rtems-specific patch currently missing from
upstream for rtems ;)

TIA,
	Ralf


[-- Attachment #2: binutils-rtems-20070807-1.diff --]
[-- Type: text/x-patch, Size: 686 bytes --]

2007-08-07	Ralf Corsépius <ralf.corsepius@rtems.org>

	* configure.tgt: Add bfin-*rtems*.

diff -uNr binutils-2.17.90.orig/ld/configure.tgt binutils-2.17.90/ld/configure.tgt
--- binutils-2.17.90.orig/ld/configure.tgt	2007-08-06 22:00:19.000000000 +0200
+++ binutils-2.17.90/ld/configure.tgt	2007-08-07 08:42:24.000000000 +0200
@@ -113,6 +113,10 @@
 			targ_extra_emuls="elf32bfinfd"
 			targ_extra_libpath=$targ_extra_emuls
 			;;
+bfin-*-rtems*)		targ_emul=elf32bfin;
+			targ_extra_emuls="elf32bfinfd"
+			targ_extra_libpath=$targ_extra_emuls
+			;;
 bfin-*-uclinux*)	targ_emul=elf32bfin;
 			targ_extra_emuls="elf32bfinfd"
 			targ_extra_libpath=$targ_extra_emuls

Re: Add bfin-*rtems* [was: Binutils 2.18 prep]

[Nick Clifton]

Hi Ralf,

> I'd appreciate it, if somebody could apply the patch below to the branch
> and HEAD. It's the only rtems-specific patch currently missing from
> upstream for rtems ;)

Done.

Cheers
   Nick

Re: Binutils 2.18 prep

[Matthias Klose]

Daniel Jacobowitz schrieb:
> On Mon, Jul 30, 2007 at 12:51:46PM -0400, Daniel Jacobowitz wrote:
>> Hi folks,
>>
>> Obviously that didn't happen.  Let's try again.  If you know of any
>> issues in HEAD that should not be in a stable release, please let me
>> know.  Otherwise, I will tentatively plan:
>>
>> - Branch 6th August
>> - Release 27th August
> 
> This time, it did happen.  I have created the new branch,
> binutils-2_18-branch.  There is a snapshot from the branch in the
> snapshots directory on sourceware, which I have forwarded to the
> Translation Project.
> 
> As usual, for the next two weeks or so please feel free to apply
> bug fixes to the branch when you apply them to HEAD.  Thanks!

I see patches sent to the ML labeled as bug fixes, but they are not applied to
the branch. Could these bug fixes be applied to the branch as well?

http://sourceware.org/ml/binutils/2007-08/msg00115.html
http://sourceware.org/ml/binutils/2007-08/msg00116.html
http://sourceware.org/ml/binutils/2007-08/msg00120.html
http://sourceware.org/ml/binutils/2007-08/msg00121.html

Matthias

Re: Binutils 2.18 prep

[Daniel Jacobowitz]

On Thu, Aug 09, 2007 at 01:45:17PM +0200, Matthias Klose wrote:
> I see patches sent to the ML labeled as bug fixes, but they are not applied to
> the branch. Could these bug fixes be applied to the branch as well?
> 
> http://sourceware.org/ml/binutils/2007-08/msg00115.html

SSE4 fixes in Intel mode.  I don't think this is especially important
for the branch, but it isn't harmful either, so I merged it.

> http://sourceware.org/ml/binutils/2007-08/msg00116.html

This thread appears to be a dud.

> http://sourceware.org/ml/binutils/2007-08/msg00120.html

Alan has already applied this to the branch.

> http://sourceware.org/ml/binutils/2007-08/msg00121.html

Ditto.

-- 
Daniel Jacobowitz
CodeSourcery