using multiple trees with subversion

[François-Xavier Coudert]

Hi all,

I've been playing with the svn test repo during the last few days,
updating my own (few) scripts and all, and it's been going very
smoothly. The only thing that's worrying me is disk usage.

I do only have small involvement in gcc, preparing few patches (never
more than 5 at a time) on limited areas (gcc/fortran, libgfortran and
gcc/testsuite), always on mainline or 4.0 branch. The way I manage to
keep mind sanity right now is to have a few complete trees (one for
4.0 and 3-4 for mainline, each one with a local changes), called
gcc-newintrinsics, gcc-fpe, ...
Having 5 subversion trees will need much more space (for local
pristine copies), which I don't really have. Is there any way to force
subversion use one pristine tree for all modified trees, or is my way
of handling things completely rotten?

I welcome any advice... Thanks!

FX

Re: using multiple trees with subversion

[Florian Weimer]

* François-Xavier Coudert:

> Having 5 subversion trees will need much more space (for local
> pristine copies), which I don't really have. Is there any way to force
> subversion use one pristine tree for all modified trees, or is my way
> of handling things completely rotten?

You could try svk, it doesn't use pristine copies.

Re: using multiple trees with subversion

[Giovanni Bajo]

François-Xavier Coudert <[EMAIL PROTECTED]> wrote:

> I do only have small involvement in gcc, preparing few patches (never
> more than 5 at a time) on limited areas (gcc/fortran, libgfortran and
> gcc/testsuite), always on mainline or 4.0 branch. The way I manage to
> keep mind sanity right now is to have a few complete trees (one for
> 4.0 and 3-4 for mainline, each one with a local changes), called
> gcc-newintrinsics, gcc-fpe, ...
> Having 5 subversion trees will need much more space (for local
> pristine copies), which I don't really have. Is there any way to force
> subversion use one pristine tree for all modified trees, or is my way
> of handling things completely rotten?

Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably have
support for checking out repositories with compressed local copies (or no copy
at all -- but I wouldn't suggest this, as you'd start to be slow in "svn diff",
"svn stat", etc).

You may want to look into svk though, which implements a distributed system on
the top of an exising subversion repository. svk working copies do not have a
double-copy at all.

Also I suggest you to look into "svn switch" which might be useful to you to
switch an existing working copy from a branch to another, without redownloading
the whole thing but just the differences.

Giovanni Bajo

Re: using multiple trees with subversion

[François-Xavier Coudert]

> Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably have
> support for checking out repositories with compressed local copies (or no copy
> at all -- but I wouldn't suggest this, as you'd start to be slow in "svn 
> diff",
> "svn stat", etc).

I guess no local copy would be fine with me. diff and stat should not
be much slower than in CVS, and since very rarely do a full tree
diff/stat, this is quite acceptable.

Is that so hard to implement that it's not done already? Or am I the
only person to find that disk is expensive (or working on his own
hardware, maybe)?

> You may want to look into svk though

Thanks for the link, I'll give it a try.

FX

Re: using multiple trees with subversion

[Giovanni Bajo]

François-Xavier Coudert <[EMAIL PROTECTED]> wrote:

>> Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably
>> have support for checking out repositories with compressed local copies
>> (or no copy at all -- but I wouldn't suggest this, as you'd start to be
>> slow in "svn diff", "svn stat", etc).
>
> I guess no local copy would be fine with me. diff and stat should not
> be much slower than in CVS, and since very rarely do a full tree
> diff/stat, this is quite acceptable.

Actually, once you get used to *immediate* reply to svn diff and stat, you
don't want to go back to wait for a few seconds. I know because it happens
to me all the time...

> Is that so hard to implement that it's not done already? Or am I the
> only person to find that disk is expensive (or working on his own
> hardware, maybe)?

Probably you're the only one finding disk space expensive. HDs are quite
cheap nowadays. Anyway, I'm sure SVN people would be happy if you help
finishing the summer of code project that was left undone, if you are really
interested in this. Personally I'm way more annoyed by the fact that the
local copy confuses grep, than the disk space it takes.
-- 
Giovanni Bajo

Re: using multiple trees with subversion

[Daniel Berlin]

On Wed, 2005-10-19 at 13:48 +0200, Giovanni Bajo wrote:
> François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> 
> >> Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably
> >> have support for checking out repositories with compressed local copies
> >> (or no copy at all -- but I wouldn't suggest this, as you'd start to be
> >> slow in "svn diff", "svn stat", etc).
> >
> > I guess no local copy would be fine with me. diff and stat should not
> > be much slower than in CVS, and since very rarely do a full tree
> > diff/stat, this is quite acceptable.
> 
> Actually, once you get used to *immediate* reply to svn diff and stat, you
> don't want to go back to wait for a few seconds. I know because it happens
> to me all the time...
> 
> > Is that so hard to implement that it's not done already? Or am I the
> > only person to find that disk is expensive (or working on his own
> > hardware, maybe)?
> 
> Probably you're the only one finding disk space expensive. HDs are quite
> cheap nowadays. Anyway, I'm sure SVN people would be happy if you help
> finishing the summer of code project that was left undone, if you are really
> interested in this. Personally I'm way more annoyed by the fact that the
> local copy confuses grep, than the disk space it takes.

See subversion's contrib/client-side/wcgrep :)

I use a modified version of that if i want to grep subversion dirs
recursively.

Re: using multiple trees with subversion

[Daniel Berlin]

On Wed, 2005-10-19 at 11:56 +0200, François-Xavier Coudert wrote:
> > Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably have
> > support for checking out repositories with compressed local copies (or no 
> > copy
> > at all -- but I wouldn't suggest this, as you'd start to be slow in "svn 
> > diff",
> > "svn stat", etc).
> 
> I guess no local copy would be fine with me. diff and stat should not
> be much slower than in CVS, and since very rarely do a full tree
> diff/stat, this is quite acceptable.
> 
> Is that so hard to implement that it's not done already? 

No, it's just that it doesn't bother most subversion users, AFAICT.
It's probably a bunch of stuff to slog through (Places assume the text
base is always in the working copy, etc).

Compressed working copy text base is certainly easier than no working
copy text base.

Without a working copy text base, you are more or less going to have to
pretend the user asked entirely for remote operations, and just pull the
versions from the entry file.

Again, this isn't all hard, but it is work :)


--Dan

Re: using multiple trees with subversion

[Daniel Berlin]

On Wed, 2005-10-19 at 08:14 -0400, Daniel Berlin wrote:
> On Wed, 2005-10-19 at 11:56 +0200, François-Xavier Coudert wrote:
> > > Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably 
> > > have
> > > support for checking out repositories with compressed local copies (or no 
> > > copy
> > > at all -- but I wouldn't suggest this, as you'd start to be slow in "svn 
> > > diff",
> > > "svn stat", etc).
> > 
> > I guess no local copy would be fine with me. diff and stat should not
> > be much slower than in CVS, and since very rarely do a full tree
> > diff/stat, this is quite acceptable.
> > 
> > Is that so hard to implement that it's not done already? 
> 

> Again, this isn't all hard, but it is work :)

Also, there was a summer of code student that was supposed to do it, but
ended up not doing it.

> 
> 
> --Dan
> 

Deinitialization of globals

[Piotr Wyderski]

I need to enforce a certain initialization and deinitialization order
of static variables in GCC, even between different translation units.
There is an extension called init_priority, which initializes my
variable first, but its deinitialization order is weird:

8<--

#include 

struct A {

A() {

printf("A()\n");
}

~A() {

printf("~A()\n");
}
};


struct B {

B() {

printf("B()\n");
}

~B() {

printf("~B()\n");
}
};


struct C {

C() {

printf("C()\n");
}

~C() {

printf("~C()\n");
}
};

struct D {

D() {

printf("D()\n");
}

~D() {

printf("~D()\n");
}
};

static A a;
static B b;
static C c __attribute__((init_priority(101)));
static D d;

int main(int argc, char *argv[])
{

 return 0;
}

8<--

It produces:

C()
A()
B()
D()
~C() <= deinitialization order error
~D()
~B()
~A()

But I expect:

C()
A()
B()
D()
~D()
~B()
~A()
~C()

Why isn't c destroyed at the very end? Is it a bug or a correct behaviour?
I don't see anything like attribute(deinit_priority), so how can I obtain
the
latter deinitialization order (nifty counters etc. are not allowed, because
third-party libraries do not include them)?

Best reagrds
Piotr Wyderski

A couple more subversion notes

[Daniel Berlin]

1. The entire svn repo is currently 8.5 gig on disk (the cvs repo is 3.4
gig)

About 3 gig of this is crappy tag metadata (IE from tags that weird
things have been done to, etc, so that cvs2svn can't simply make copies
like subversion would have done originally).

The svn repo also contains more history than the old cvs server, since
it has old-gcc merged into it.

I expect the repo to grow pretty slowly in reality (though 8.5 gig for
16 years isn't too bad).

I'm working on patches for svn 1.4 that will reduce the repo size to
about 4-5 gig (conservatively high) through better compression.

2. If you want context diffs, or support for -p, you need to configure
an external diff.  subversion's internal diff library always produces
unidiffs.  It is also not as featureful as gnu diff.  It was built
mainly so svn diff and friends would work without an external diff.

I have a link to how to configure an external diff on the wiki page.
It's really rather easy, and only has to be done once.

There is no need to use -N, as svn add is a command that does not
require write access.

3. Small operations (IE ls of random dirs, etc) are generally dominated
by the ssh handshake time.  Using ssh multiplexing will significantly
speed these up.

4. For people using svk, the initial svk sync will probably take a while
if you directly svk mirror. It's probably a ton faster to rsync the
repo, svk mirror from that, and then change the source of the mirror
(which should work fine, AFAIK).

5. Lastly, just to be clear, if you guys don't think the benefits
outweigh the costs, we don't have to move.
So far, the amount of dissent i've heard is pretty small, but please, if
you don't want to move (or you do), please speak up, instead of silently
suffering (or silently being in joy).

Personally, i manage a bunch of branches, so subversion is a big win for
me.
It's nice to be able to merge and tag quickly and easily.

It's nice to be able to pull the revisions to the mainline simply by
using merge, instead of generating patches and reapplying them.

It's nice to be able to rsync the repo without it touching 80 billion
files.
etc

But if it's not a win for most of us, we probably shouldn't do it.
There is no perfect revision control system.  None of the currently
production quality open source ones are any better.

--Dan

Re: A couple more subversion notes

[Paolo Bonzini]

But if it's not a win for most of us, we probably shouldn't do it.
There is no perfect revision control system.  None of the currently
production quality open source ones are any better.


I think it is natural that people start asking questions when they are 
getting ready for the real thing.  I think everybody is going to pleased 
with the transition after a few weeks.


I was pleased when I moved my projects from CVS to arch, after one or 
two weeks.  And if I was pleased with arch, I guess it cannot go worse 
with subversion...


I also have a question though.  Is it possible to only mirror a few 
given branches when setting up an svk repository?  For me, for example, 
local branches off the release branches and mainline would be more than 
enough (and would allow me to get rid of the script I just described to 
FX in the other thread...), and would save me presumably 4 gigs.


Paolo

Re: using multiple trees with subversion

[Paolo Bonzini]

Having 5 subversion trees will need much more space (for local
pristine copies), which I don't really have. Is there any way to force
subversion use one pristine tree for all modified trees, or is my way
of handling things completely rotten?


I have a script called svn-switch-patch that undoes the changes in the 
local tree and applies a patch on top of it.  It is not perfect (you 
cannot have three-way conflict resolution), but it is good enough for 
most occasions and you actually end up having *less* stuff on disk.  And 
it can be used offline exactly because of the working copy.


Paolo

Re: A couple more subversion notes

[Richard Guenther]

On 10/19/05, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > But if it's not a win for most of us, we probably shouldn't do it.
> > There is no perfect revision control system.  None of the currently
> > production quality open source ones are any better.
>
> I think it is natural that people start asking questions when they are
> getting ready for the real thing.  I think everybody is going to pleased
> with the transition after a few weeks.
>
> I was pleased when I moved my projects from CVS to arch, after one or
> two weeks.  And if I was pleased with arch, I guess it cannot go worse
> with subversion...
>
> I also have a question though.  Is it possible to only mirror a few
> given branches when setting up an svk repository?  For me, for example,
> local branches off the release branches and mainline would be more than
> enough (and would allow me to get rid of the script I just described to
> FX in the other thread...), and would save me presumably 4 gigs.

Yes, I just put some notes about how to do that on the wiki.  Though try
using a local rsync copy of the svn repository for initial sync - it seems to
take ages if going over ssh+svn.

Richard.

Re: using multiple trees with subversion

[Ranjit Mathew]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Giovanni Bajo wrote:
> 
> Probably you're the only one finding disk space expensive. HDs are quite
> cheap nowadays. Anyway, I'm sure SVN people would be happy if you help

Well, I'm another person who's concerned about growing
local copy sizes. As it stands, checking out multiple
branches from the current GCC CVS repository *severely*
strains the available disc space on my home PC.

In my case, I have two hard discs, a CD-ROM drive
and a DVD-ROM drive that completely fill out the
available IDE channels. (There might be a way
to work around this limitation, but I don't know
of it yet.)

Thanks,
Ranjit.

- --
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDVlCYYb1hx2wRS48RAntDAKCfOLR29U1V193NJQbm4AoQ5uZj9QCgiQLl
640Z6Xb1AWdlMn5si6QXhBo=
=X0Lf
-END PGP SIGNATURE-

Re: A couple more subversion notes

[Daniel Berlin]

On Wed, 2005-10-19 at 09:42 -0400, Daniel Berlin wrote:
> 1. The entire svn repo is currently 8.5 gig on disk (the cvs repo is 3.4
> gig)

Just to clarify, this is the entire repository on gcc.gnu.org, not the
checked out sources.

Re: A couple more subversion notes

[Daniel Berlin]

On Wed, 2005-10-19 at 15:54 +0200, Paolo Bonzini wrote:
> > But if it's not a win for most of us, we probably shouldn't do it.
> > There is no perfect revision control system.  None of the currently
> > production quality open source ones are any better.
> 
> I think it is natural that people start asking questions when they are 
> getting ready for the real thing.  I think everybody is going to pleased 
> with the transition after a few weeks.
> 
> I was pleased when I moved my projects from CVS to arch, after one or 
> two weeks.  And if I was pleased with arch, I guess it cannot go worse 
> with subversion...
> 
> I also have a question though.  Is it possible to only mirror a few 
> given branches when setting up an svk repository?

You can simply tell svk to sync starting at a given revision, if
you don't want history back to the beginning of the planet
> 

I'd find the oldest branch you want to care about, and then just sync
starting with that revision.

You can tell what revision a branch started at using a simple binary
search (assuming it was created once).

IE 
svn ls svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch@  

(This asks for the path as it existed in revision number.
If you used -r, it would find where it was copied from and follow it
back through renames, etc. There is a section on peg revs, as these are
called, in the book)

svn ls will give you an easily greppable error message if the path
doesn't exist.

It will take at max, log(num revisions)/log(2) (currently 12 :P) svn
ls's  to find the beginning of the branch 

I did it manually (and discovered, for example, that gcc-4_0-branch was
created in revision 95538

The following script, written by Richard Guenther, will do this for you:
#!/bin/sh

# search repository tag

if test -z "$1"; then
  exit 1
fi

rev=`svn info $1/trunk | grep '^Revision:' | sed -e 's/Revision: //'`
echo trunk is at rev $rev
width=$[$rev / 2]
rev=$[$rev - $width]
while true; do
  width=$[$width / 2]
  echo svn info $1/[EMAIL PROTECTED]
  svn info $1/[EMAIL PROTECTED] | grep "Not a valid URL"
  if ! test $? == 0; then
echo  - exists.
rev=$[$rev - $width]
  else
rev=$[$rev + $width]
  fi
  if test $width == 0; then
break;
  fi
done

Re: A couple more subversion notes

[Daniel Berlin]

> Yes, I just put some notes about how to do that on the wiki.  Though try
> using a local rsync copy of the svn repository for initial sync - it seems to
> take ages if going over ssh+svn.


Luckily, only one person needs to do it. We can then simply produce a
tarball of the .svk/local dir, let people download that, and you can add
that to your depotmap.

(i'm told by svk developers and users that this will work).

Richard Guenther actualy had a nice idea, which is to have three or four
of these

1. Full history
2. 4.0+
3. 3.4+
4. just HEAD

I'm happy to do this to get people started.



> 
> Richard.

Re: A couple more subversion notes

[Arnaud Charlet]

Here are my first impressions on trying to use subversion.

Note that I didn't go to any doc or wiki page yet, I simply copy/pasted
the commands I saw on the gcc list. I am familiar with cvs commands and
expect most things to be handled similarly.

- first check out:

svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk

took a lot of time, but I assume this is somewhat expected, and not really
a concern as I am not doing complete check outs often.

Then tried a few "cvs" things without much success:

$ cd trunk/gcc/ada
$ svn status Makefile.in
-> didn't get any answer
$ svn status --help Makefile.in
-> saw --verbose and --show-updates options

$ svn status --verbose Makefile.in
   105364   103893 charlet  Makefile.in

Not clear how to interpret this output without having to go to the doc,
no easy way to guess with my cvs knowledge, nor with my english knowledge.

I guess I was expecting something more verbose ala cvs, e.g a real "status" 
in english, such as up-to-date, locally modified, needs merge, ...
instead of "nothing" or "M" which are rather cryptic for a subversion
novice.

$ svn status --show-updates Makefile.in
Status against revision: 105364

All right, I guess my Makefile.in file is at revision 105364.

Then:

$ svn log Makefile.in | more

figure out that the last two revs are 105364 and 103893 (and now I guess
I understand svn status --verbose output).

Note: coming from a cvs background, having non incremental version numbers
*per file* is very disruptive and non intuitive. I suspect it will take
me some time to adjust to this. Any suggestions/tricks welcome.

Now:

$ svn diff -r101581 -r103893 Makefile.in
svn: Multiple revision arguments encountered; try '-r M:N' instead of '-r M -r 
N'

All right, not very friendly to cvs users, but ok...

$ time svn diff -r101581:103893 Makefile.in
[repeated several times]

took between 16 and 22 seconds. 18 seconds typically.

Now, did a cvs diff -r1.120 -r1.121 Makefile.in

took between 3 and 5 seconds. 3.5 seconds typically.

Is there any way to improve such svn diff operation ? (Note that
I frequently do cvs diff on arbitrary revisions, not just the last two,
although doing cvs diff -rHEAD is probably the most frequent operation
I rely upon).

There is a factor more than 5 between svn diff and cvs diff in my set up
(svn 1.2.3, redhat 8), and this will likely significantly impact my work on
gcc

Log isn't as bad, but still annoying:

$ time svn log Makefile.in
gives about 5.5 seconds

$ time cvs log Makefile.in
gives about 4.5 seconds

Here, there's a 1 second difference (about 22%).

My 2 cents.

Arno

Re: A couple more subversion notes

[Arnaud Charlet]

Oh I forgot: tied a couple of svn commit operations, which,
after having set the EDITOR env variable, went fine, no troubles.

Arno

Re: A couple more subversion notes

[Richard Guenther]

On 10/19/05, Arnaud Charlet <[EMAIL PROTECTED]> wrote:
> Here are my first impressions on trying to use subversion.
>
> Note that I didn't go to any doc or wiki page yet, I simply copy/pasted
> the commands I saw on the gcc list. I am familiar with cvs commands and
> expect most things to be handled similarly.
>
> - first check out:
>
> svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
>
> took a lot of time, but I assume this is somewhat expected, and not really
> a concern as I am not doing complete check outs often.
>
> Then tried a few "cvs" things without much success:
>
> $ cd trunk/gcc/ada
> $ svn status Makefile.in
> -> didn't get any answer
> $ svn status --help Makefile.in
> -> saw --verbose and --show-updates options
>
> $ svn status --verbose Makefile.in
>105364   103893 charlet  Makefile.in
>
> Not clear how to interpret this output without having to go to the doc,
> no easy way to guess with my cvs knowledge, nor with my english knowledge.
>
> I guess I was expecting something more verbose ala cvs, e.g a real "status"
> in english, such as up-to-date, locally modified, needs merge, ...
> instead of "nothing" or "M" which are rather cryptic for a subversion
> novice.
>
> $ svn status --show-updates Makefile.in
> Status against revision: 105364
>
> All right, I guess my Makefile.in file is at revision 105364.
>
> Then:
>
> $ svn log Makefile.in | more
>
> figure out that the last two revs are 105364 and 103893 (and now I guess
> I understand svn status --verbose output).
>
> Note: coming from a cvs background, having non incremental version numbers
> *per file* is very disruptive and non intuitive. I suspect it will take
> me some time to adjust to this. Any suggestions/tricks welcome.
>
> Now:
>
> $ svn diff -r101581 -r103893 Makefile.in
> svn: Multiple revision arguments encountered; try '-r M:N' instead of '-r M 
> -r N'
>
> All right, not very friendly to cvs users, but ok...
>
> $ time svn diff -r101581:103893 Makefile.in
> [repeated several times]
>
> took between 16 and 22 seconds. 18 seconds typically.
>
> Now, did a cvs diff -r1.120 -r1.121 Makefile.in
>
> took between 3 and 5 seconds. 3.5 seconds typically.
>
> Is there any way to improve such svn diff operation ? (Note that
> I frequently do cvs diff on arbitrary revisions, not just the last two,
> although doing cvs diff -rHEAD is probably the most frequent operation
> I rely upon).
>
> There is a factor more than 5 between svn diff and cvs diff in my set up
> (svn 1.2.3, redhat 8), and this will likely significantly impact my work on
> gcc

I think people really want to use svk for their day-to-day work, because
 1. such diffs are then local operations
 2. you can have local branches which you can use instead of having
 N checked out modified trees.

Richard.

Re: A couple more subversion notes

[Paolo Carlini]

Richard Guenther wrote:

>I think people really want to use svk for their day-to-day work, because
> 1. such diffs are then local operations
> 2. you can have local branches which you can use instead of having
> N checked out modified trees.
>  
>
Feel free to stress this point on the wiki... ;)

Paolo.

Re: using multiple trees with subversion

[Vincent Lefevre]

On 2005-10-19 13:48:36 +0200, Giovanni Bajo wrote:
> Probably you're the only one finding disk space expensive.

One can also write data on memory cards and they are expensive.
This would be important to use Subversion on a PDA.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: A couple more subversion notes

[Arnaud Charlet]

Thanks for your reply and suggestion.
A couple of questions, comments below:

> I think people really want to use svk for their day-to-day work, because
>  1. such diffs are then local operations
>  2. you can have local branches which you can use instead of having
>  N checked out modified trees.

How are sync handled ? that is to say, how much time will it take to
do the update and how frequently do I need to do them.

How is diff -rHEAD handled with svk if my check out/database isn't synced ?

Also, I guess that would mean having 8.5 gigs dedicated
to the GCC rep (without talking about the check outs and builds) on
my machine. I know that disk space is cheap, but I would need to build a
new laptop or reformat my drive in order to achieve that... And still,
having 10gigs less on a laptop's hard drive is quite annoying.

Arno

Re: A couple more subversion notes

[Andrew Haley]

Arnaud Charlet writes:
 > Here are my first impressions on trying to use subversion.
 > 
 > Note that I didn't go to any doc or wiki page yet, I simply copy/pasted
 > the commands I saw on the gcc list. I am familiar with cvs commands and
 > expect most things to be handled similarly.
 > 
 > - first check out:
 > 
 > svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
 > 
 > took a lot of time, but I assume this is somewhat expected, and not really
 > a concern as I am not doing complete check outs often.
 > 
 > Then tried a few "cvs" things without much success:
 > 
 > $ cd trunk/gcc/ada
 > $ svn status Makefile.in
 > -> didn't get any answer
 > $ svn status --help Makefile.in
 > -> saw --verbose and --show-updates options
 > 
 > $ svn status --verbose Makefile.in
 >105364   103893 charlet  Makefile.in
 > 
 > Not clear how to interpret this output without having to go to the doc,
 > no easy way to guess with my cvs knowledge, nor with my english knowledge.
 > 
 > I guess I was expecting something more verbose ala cvs, e.g a real "status" 
 > in english, such as up-to-date, locally modified, needs merge, ...
 > instead of "nothing" or "M" which are rather cryptic for a subversion
 > novice.
 > 
 > $ svn status --show-updates Makefile.in
 > Status against revision: 105364
 > 
 > All right, I guess my Makefile.in file is at revision 105364.

It seems to be incredibly hard to find out which branch a file is on.  

[EMAIL PROTECTED] gcc-head-test]$ svn status --verbose ChangeLog
   105366   104478 mmitchel ChangeLog

Now, I happen to know that this is gcc-4_0-branch, and presumably if I
make any changes and check it back in that's where the changes will
go.  But "svn ls branches" says

 105358 dberlin Oct 16 01:53 gcc-4_0-branch/

So, how on Earth do I go from "105366 104478" to gcc-4_0-branch ?

Andrew.

Re: A couple more subversion notes

[Daniel Berlin]

On Wed, 2005-10-19 at 16:44 +0200, Arnaud Charlet wrote:
> Here are my first impressions on trying to use subversion.
> 
> Note that I didn't go to any doc or wiki page yet, I simply copy/pasted
> the commands I saw on the gcc list. I am familiar with cvs commands and
> expect most things to be handled similarly.
> 
> - first check out:
> 
> svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
> 
> took a lot of time, but I assume this is somewhat expected, and not really
> a concern as I am not doing complete check outs often.
> 
> Then tried a few "cvs" things without much success:
> 
> $ cd trunk/gcc/ada
> $ svn status Makefile.in
> -> didn't get any answer
> $ svn status --help Makefile.in
> -> saw --verbose and --show-updates options
> 
> $ svn status --verbose Makefile.in
>105364   103893 charlet  Makefile.in
> 
> Not clear how to interpret this output without having to go to the doc,
> no easy way to guess with my cvs knowledge, nor with my english knowledge.
> 
> I guess I was expecting something more verbose ala cvs, e.g a real "status" 
> in english, such as up-to-date, locally modified, needs merge, ...
> instead of "nothing" or "M" which are rather cryptic for a subversion
> novice.
> 
> $ svn status --show-updates Makefile.in
> Status against revision: 105364
> 
> All right, I guess my Makefile.in file is at revision 105364.
> 
> Then:
> 
> $ svn log Makefile.in | more
> 
> figure out that the last two revs are 105364 and 103893 (and now I guess
> I understand svn status --verbose output).
> 
> Note: coming from a cvs background, having non incremental version numbers
> *per file* is very disruptive and non intuitive. I suspect it will take
> me some time to adjust to this. Any suggestions/tricks welcome.


> Now:
> 
> $ svn diff -r101581 -r103893 Makefile.in
> svn: Multiple revision arguments encountered; try '-r M:N' instead of '-r M 
> -r N'
> 
> All right, not very friendly to cvs users, but ok...
> 
> $ time svn diff -r101581:103893 Makefile.in
> [repeated several times]
> 
> took between 16 and 22 seconds. 18 seconds typically.
> 
Most of this is ssh overhead, because your diff is so small.

The ssh multiplexing stuff just written up on the wiki should help.

The svn protocol was built for multiple cheap connections, which is true
over tcp.

We use svn+ssh because that's the auth scheme cvs used, and all we have
implemented to auth people. Otherwise, we'd use svn+ssl or something.

However, this requires a bunch of svn protocol connections tunneled
through ssh connections :(

time svn diff -r101581:103893
svn://gcc.gnu.org/svn/gcc/trunk/gcc/ada/Makefile.in 

(3-5 seconds)

vs

time svn diff -r101581:103893 svn
+ssh://gcc.gnu.org/svn/gcc/trunk/gcc/ada/Makefile.in 

(15 seconds)

Sad, but true.

--Dan

Re: A couple more subversion notes

[Andreas Schwab]

Daniel Berlin <[EMAIL PROTECTED]> writes:

> 3. Small operations (IE ls of random dirs, etc) are generally dominated
> by the ssh handshake time.  Using ssh multiplexing will significantly
> speed these up.

How can I tell ssh not to barf if the ControlPath does not exist?  Also,
you can't share the config file with an older ssh version because it will
barf about the unknown config option.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: A couple more subversion notes

[Paolo Carlini]

Daniel Berlin wrote:

>5. Lastly, just to be clear, if you guys don't think the benefits
>outweigh the costs, we don't have to move.
>So far, the amount of dissent i've heard is pretty small, but please, if
>you don't want to move (or you do), please speak up, instead of silently
>suffering (or silently being in joy).
>  
>
Thanks Danny for asking. I'm reading the various messages coming to the list 
and, well, I'm *worried* the benefits will *not* outweigh the costs for many of 
us.

Sorry for the harsh and naive question: *which* are the benefits for people 
*not* managing many branches?

Paolo.

Re: A couple more subversion notes

[Giovanni Bajo]

Arnaud Charlet <[EMAIL PROTECTED]> wrote:

> Not clear how to interpret this output without having to go to the doc,
> no easy way to guess with my cvs knowledge, nor with my english knowledge.
>
> I guess I was expecting something more verbose ala cvs, e.g a real
"status"
> in english, such as up-to-date, locally modified, needs merge, ...
> instead of "nothing" or "M" which are rather cryptic for a subversion
> novice.

It's the same, with a minimal non-verbose output, and a default which does
not require any connection to the server. You'll learn to use "svn status"
without any argument to find out "what's up" in your working copy,
irrespective of the server. If it does not say anything, your working copy
is pristine.

> $ svn status --show-updates Makefile.in
> Status against revision: 105364

This would show pending updates as you expect.

> Note: coming from a cvs background, having non incremental version numbers
> *per file* is very disruptive and non intuitive. I suspect it will take
> me some time to adjust to this. Any suggestions/tricks welcome.

I don't think there are suggestions or tricks. You'll just have to get used
to the idea that the changesets are atomic, and they uniquely identify the
whole tree. When you said that your repository is version 105364, your svn
status is empty, and you see a bug, I can download that very version and
reproduce it, without having to match your top of ChangeLog, or other weird
things.

Per-file, you can see the history to see when the file was changed. Noice
that you can use --verbose to see other files changed in the same commit,
which is very handy (no more wasted time looking for the whole patch in
gcc-cvs or in gcc-patches).

> took between 16 and 22 seconds. 18 seconds typically.
>
> Now, did a cvs diff -r1.120 -r1.121 Makefile.in
>
> took between 3 and 5 seconds. 3.5 seconds typically.

Out of curiosity, are you comparing anonymous CVS versus svn+ssh? In that
case, it's apple and oranges. Do some ssh multiplexing and get speed back.

> Is there any way to improve such svn diff operation ? (Note that
> I frequently do cvs diff on arbitrary revisions, not just the last two,
> although doing cvs diff -rHEAD is probably the most frequent operation
> I rely upon).

"svk" is a tool that lets you mirror the entire repository (or a subset of),
checkout many copies from your local mirror, diff whatever with whatever,
commit into your local repository, and finally push changes into the
official repository. I believe it's going to be very handy for the average
GCC developer. People are still discussing about it (see other mails) and I
believe a Wiki page will be setup about it.
-- 
Giovanni Bajo

Re: A couple more subversion notes

[Giovanni Bajo]

Andreas Schwab <[EMAIL PROTECTED]> wrote:

>> 3. Small operations (IE ls of random dirs, etc) are generally dominated
>> by the ssh handshake time.  Using ssh multiplexing will significantly
>> speed these up.
>
> How can I tell ssh not to barf if the ControlPath does not exist?  Also,
> you can't share the config file with an older ssh version because it will
> barf about the unknown config option.


I put ControlPath in the config file, and then run "ssh -fMN host" at
startup. When is it barfing for you? If I remove the socket file, it just
does a normal connection.
-- 
Giovanni Bajo

Re: A couple more subversion notes

[Steven Bosscher]

On Wednesday 19 October 2005 17:06, Paolo Carlini wrote:
> Daniel Berlin wrote:
> >5. Lastly, just to be clear, if you guys don't think the benefits
> >outweigh the costs, we don't have to move.
> >So far, the amount of dissent i've heard is pretty small, but please, if
> >you don't want to move (or you do), please speak up, instead of silently
> >suffering (or silently being in joy).
>
> Thanks Danny for asking. I'm reading the various messages coming to the
> list and, well, I'm *worried* the benefits will *not* outweigh the costs
> for many of us.
>
> Sorry for the harsh and naive question: *which* are the benefits for people
> *not* managing many branches?

Hmm, let's see.  The ones I care about most are:

1) Atomic commits, which make regression hunting a lot easier.
   You can pinpoint exactly one patch, one revision, as the
   thing to blame.  Right now the regression hunter can from
   time to time do checkouts from a data+time when someone was
   just checking in a patch.  With SVN, this is not a problem.

2) Ability to rename and move files.  Have you ever looked at
   the messy structure of gcc (i.e. the compiler proper)?  And
   don't you ever have the feeling that some libstdc++ file is
   in the wrong place, but you don't want to move it because
   it breaks the revision history?  SVN helps here.

And less important but still nice:
3) Faster tagging, so you don't have to worry about not checking
   out something when a gcc snapshot cron job is running

Re: A couple more subversion notes

[Daniel Berlin]

> It seems to be incredibly hard to find out which branch a file is on.  

Huh?

The file is where it is.
Branches are just seperate directories.
If it's in the 4.0 directory, it's on the 4.0 branch

Revision numbers don't tell you what branch something is on.
They tell you what revision the repository is at, and the changesets
that have been applied to the repository.

If you want to know where the file is, ask where the file is :)

> 
> [EMAIL PROTECTED] gcc-head-test]$ svn status --verbose ChangeLog
>105366   104478 mmitchel ChangeLog
> 
> Now, I happen to know that this is gcc-4_0-branch, and presumably if I
> make any changes and check it back in that's where the changes will
> go. 

svn info ChangeLog

>  But "svn ls branches" says
> 
>  105358 dberlin Oct 16 01:53 gcc-4_0-branch/
> 

Which is the last revision where gcc-4.0-branch was changed.


> So, how on Earth do I go from "105366 104478" to gcc-4_0-branch ?
You don't.
you use svn info on the ChangeLog.
and it will say:


Path: ChangeLog
Name: ChangeLog
URL: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/ChangeLog
Repository UUID: 284566a7-fc02-0410-aa54-b5c5f2f15645
Revision: 105366
Node Kind: file
Schedule: normal
Last Changed Author: ebotcazou
Last Changed Rev: 105335
Last Changed Date: 2005-10-12 18:14:32 -0400 (Wed, 12 Oct 2005)
Text Last Updated: 2005-10-19 11:07:35 -0400 (Wed, 19 Oct 2005)
Properties Last Updated: 2005-10-19 11:06:53 -0400 (Wed, 19 Oct 2005)
Checksum: 7b909ad6508f526b54a46d5d609022f8

> Andrew.
> 

Re: A couple more subversion notes

[Arnaud Charlet]

> Most of this is ssh overhead, because your diff is so small.

I disagree, the diff isn't small, it is of a typical/reasonable size I
would say.

> The ssh multiplexing stuff just written up on the wiki should help.

Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
so I cannot test that right now.

Arno

Re: A couple more subversion notes

[Daniel Jacobowitz]

On Wed, Oct 19, 2005 at 05:12:32PM +0200, Arnaud Charlet wrote:
> > Most of this is ssh overhead, because your diff is so small.
> 
> I disagree, the diff isn't small, it is of a typical/reasonable size I
> would say.
> 
> > The ssh multiplexing stuff just written up on the wiki should help.
> 
> Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
> so I cannot test that right now.

Or, use the svn protocol instead for read operations?  I believe you
can do this using svn switch.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: A couple more subversion notes

[Daniel Jacobowitz]

On Wed, Oct 19, 2005 at 05:03:03PM +0200, Andreas Schwab wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
> 
> > 3. Small operations (IE ls of random dirs, etc) are generally dominated
> > by the ssh handshake time.  Using ssh multiplexing will significantly
> > speed these up.
> 
> How can I tell ssh not to barf if the ControlPath does not exist?  Also,

It shouldn't; it should automatically open a normal connection.  This
may be a fix in newer versions of ssh.

> you can't share the config file with an older ssh version because it will
> barf about the unknown config option.

Yes; if you know how to pass arguments to SVN's invocation of ssh, you
can use that instead.  I only put it in the config file because I
didn't feel like looking up the svn docs this morning.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: A couple more subversion notes

[Arnaud Charlet]

> Out of curiosity, are you comparing anonymous CVS versus svn+ssh? In that

For your curiousity, no. I am comparing two write-access repositories
(CVS and svn+ssh).

> case, it's apple and oranges. Do some ssh multiplexing and get speed back.

I first need to update to openssh 4.0 which will take some time...

But indeed, if this single change gets speed comparable to cvs, I'll be
reasonably happy.

The main issue is really with svn status and the handling of versions and
branches which seems to be quite different and quite disruptive for cvs
users.

> "svk" is a tool that lets you mirror the entire repository (or a subset of),
> checkout many copies from your local mirror, diff whatever with whatever,
> commit into your local repository, and finally push changes into the
> official repository. I believe it's going to be very handy for the average
> GCC developer. People are still discussing about it (see other mails) and I
> believe a Wiki page will be setup about it.

Thanks.
I'll wait for the outcome of this discussion. So far, it's not clear that svk
will fit well in my set up.

Arno

Re: A couple more subversion notes

[Richard Guenther]

On 10/19/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 19, 2005 at 05:12:32PM +0200, Arnaud Charlet wrote:
> > > Most of this is ssh overhead, because your diff is so small.
> >
> > I disagree, the diff isn't small, it is of a typical/reasonable size I
> > would say.
> >
> > > The ssh multiplexing stuff just written up on the wiki should help.
> >
> > Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
> > so I cannot test that right now.
>
> Or, use the svn protocol instead for read operations?  I believe you
> can do this using svn switch.

svn should probably be told to do that automatically for read operations,
if available.  It will also take some load off the server for not
doing handshaking
and encryption.

Richard.

Re: A couple more subversion notes

[Daniel Berlin]

On Wed, 2005-10-19 at 17:12 +0200, Arnaud Charlet wrote:
> > Most of this is ssh overhead, because your diff is so small.
> 
> I disagree, the diff isn't small, it is of a typical/reasonable size I
> would say.
> 

I mean bytewise, it is small compared to the overhead of ssh.
It's probably 2k compressed
:)

Re: A couple more subversion notes

[Andrew Haley]

Daniel Berlin writes:
 > 
 > > It seems to be incredibly hard to find out which branch a file is on.  
 > 
 > Huh?
 > 
 > The file is where it is.
 > Branches are just seperate directories.
 > If it's in the 4.0 directory, it's on the 4.0 branch
 > 
 > Revision numbers don't tell you what branch something is on.
 > They tell you what revision the repository is at, and the changesets
 > that have been applied to the repository.
 > 
 > If you want to know where the file is, ask where the file is :)
 > 
 > > 
 > > [EMAIL PROTECTED] gcc-head-test]$ svn status --verbose ChangeLog
 > >105366   104478 mmitchel ChangeLog
 > > 
 > > Now, I happen to know that this is gcc-4_0-branch, and presumably if I
 > > make any changes and check it back in that's where the changes will
 > > go. 
 > 
 > svn info ChangeLog

Aah, that's the key.  Where we have one command in CVS, "status",
which tells us which branch a file is on and its status, we now have
two separate commands, "status" and "info".  Easy enough, once you
know...

Andrew.

Re: A couple more subversion notes

[Daniel Jacobowitz]

On Wed, Oct 19, 2005 at 05:17:32PM +0200, Arnaud Charlet wrote:
> The main issue is really with svn status and the handling of versions and
> branches which seems to be quite different and quite disruptive for cvs
> users.

I think that "svn info" is a better match for "cvs status" than "svn
status" is.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: A couple more subversion notes

[Daniel Jacobowitz]

On Wed, Oct 19, 2005 at 05:18:26PM +0200, Richard Guenther wrote:
> On 10/19/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> > On Wed, Oct 19, 2005 at 05:12:32PM +0200, Arnaud Charlet wrote:
> > > > Most of this is ssh overhead, because your diff is so small.
> > >
> > > I disagree, the diff isn't small, it is of a typical/reasonable size I
> > > would say.
> > >
> > > > The ssh multiplexing stuff just written up on the wiki should help.
> > >
> > > Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
> > > so I cannot test that right now.
> >
> > Or, use the svn protocol instead for read operations?  I believe you
> > can do this using svn switch.
> 
> svn should probably be told to do that automatically for read operations,
> if available.  It will also take some load off the server for not
> doing handshaking
> and encryption.

I admit that'd be a pretty slick feature.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: A couple more subversion notes

[Giovanni Bajo]

Andrew Haley <[EMAIL PROTECTED]> wrote:

> It seems to be incredibly hard to find out which branch a file is on.

"svn info file". More typically, "snv info | grep URL" will tell you which
branch was the current working copy pulled from.

 > [EMAIL PROTECTED] gcc-head-test]$ svn status --verbose ChangeLog
>105366   104478 mmitchel ChangeLog
>
> Now, I happen to know that this is gcc-4_0-branch, and presumably if I
> make any changes and check it back in that's where the changes will
> go.  But "svn ls branches" says
>
>  105358 dberlin Oct 16 01:53 gcc-4_0-branch/
>
> So, how on Earth do I go from "105366 104478" to gcc-4_0-branch ?

Revisions and branches have nothing to do. It's not like CVS.
-- 
Giovanni Bajo

Re: A couple more subversion notes

[Daniel Berlin]

On Wed, 2005-10-19 at 11:15 -0400, Daniel Jacobowitz wrote:
> On Wed, Oct 19, 2005 at 05:12:32PM +0200, Arnaud Charlet wrote:
> > > Most of this is ssh overhead, because your diff is so small.
> > 
> > I disagree, the diff isn't small, it is of a typical/reasonable size I
> > would say.
> > 
> > > The ssh multiplexing stuff just written up on the wiki should help.
> > 
> > Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
> > so I cannot test that right now.
> 
> Or, use the svn protocol instead for read operations?  I believe you
> can do this using svn switch.
> 
Yes
you can svn switch --relocate to change the url of the repo

Re: A couple more subversion notes

[Andreas Schwab]

"Giovanni Bajo" <[EMAIL PROTECTED]> writes:

> I put ControlPath in the config file, and then run "ssh -fMN host" at
> startup. When is it barfing for you?

According to the wiki ssh is supposed to ignore the controlpath when it
doesn't exist, but instead it barfs.

> If I remove the socket file, it just does a normal connection.

It doesn't for me.

$ ssh gcc.gnu.org
Couldn't connect to /var/tmp/schwab/ssh_%h: No such file or directory

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: A couple more subversion notes

[Giovanni Bajo]

Steven Bosscher <[EMAIL PROTECTED]> wrote:

>> Thanks Danny for asking. I'm reading the various messages coming to the
>> list and, well, I'm *worried* the benefits will *not* outweigh the costs
>> for many of us.
>>
>> Sorry for the harsh and naive question: *which* are the benefits for
people
>> *not* managing many branches?
>
> Hmm, let's see.  The ones I care about most are:
>
> 1) Atomic commits, which make regression hunting a lot easier.
>You can pinpoint exactly one patch, one revision, as the
>thing to blame.  Right now the regression hunter can from
>time to time do checkouts from a data+time when someone was
>just checking in a patch.  With SVN, this is not a problem.
>
> 2) Ability to rename and move files.  Have you ever looked at
>the messy structure of gcc (i.e. the compiler proper)?  And
>don't you ever have the feeling that some libstdc++ file is
>in the wrong place, but you don't want to move it because
>it breaks the revision history?  SVN helps here.
>
> And less important but still nice:
> 3) Faster tagging, so you don't have to worry about not checking
>out something when a gcc snapshot cron job is running

I'll add others:

4) Uniquely identification of a tree with a single number. "In my pristine
tree, revision 567890, I see this bug". That's unique.
5) Much much faster management of working copies: "svn diff" / "svn status"
do not require server connection. "what's up in my tree" and "what did I
change" can be answered in milliseconds.
6) Much easier reversion of patches for testing purposes, since you can
easily extract and revert an atomic changeset.
7) Much easier generation of proper diffs to send mail to the lists, since
you can "svn add" and "svn delete" without write access to the repository.
8) Fast switch of working copies from a branch to another, *maintaining* the
local changes. This is very handy.
9) Much easier backport of patches to release branches: "svn
merge -r123456", which also correctly remove/add/rename files as needed.
10) Getting rid forever of the problem with DOS newlines in source files.

I would also notice that most people don't RTFM. I spent many efforts in
writing the Wiki page, and the benefits of SVN are apparent if you spend
some time reading it and studying the thing a little. To make things better,
something *has* to change. You can't expect SVN to be *identical* to CVS,
but it's very very close.
-- 
Giovanni Bajo

Re: A couple more subversion notes

[Giovanni Bajo]

Andreas Schwab <[EMAIL PROTECTED]> wrote:

>> If I remove the socket file, it just does a normal connection.
> 
> It doesn't for me.
> 
> $ ssh gcc.gnu.org
> Couldn't connect to /var/tmp/schwab/ssh_%h: No such file or directory

Ah, maybe it's a later fix? I'm using:

$ ssh -V
OpenSSH_4.2p1, OpenSSL 0.9.7f 22 Mar 2005

-- 
Giovanni Bajo

Re: A couple more subversion notes

[Giovanni Bajo]

Arnaud Charlet <[EMAIL PROTECTED]> wrote:

> The main issue is really with svn status and the handling of versions and
> branches which seems to be quite different and quite disruptive for cvs
> users.


Branches is where we expect the most from SVN, compared to CVS. The wiki
part about management of branches is a little confusing, indeed. I'll try to
reword it to make it easier. There is also a little tool (svnmerge) which
helps managing branches.

If you care elaborating on which your typical cvs procedures for branch
management are (I'd separate release branches from dev branches for
clarity), I can work out for you the correct SVN counterparts, which - I'm
sure - they're going to be more than satisfying.
-- 
Giovanni Bajo

Re: A couple more subversion notes

[Paolo Carlini]

Giovanni Bajo wrote:

>I'll add others:
>
>4) Uniquely identification of a tree with a single number. "In my pristine
>tree, revision 567890, I see this bug". That's unique.
>5) Much much faster management of working copies: "svn diff" / "svn status"
>do not require server connection. "what's up in my tree" and "what did I
>change" can be answered in milliseconds.
>6) Much easier reversion of patches for testing purposes, since you can
>easily extract and revert an atomic changeset.
>7) Much easier generation of proper diffs to send mail to the lists, since
>you can "svn add" and "svn delete" without write access to the repository.
>8) Fast switch of working copies from a branch to another, *maintaining* the
>local changes. This is very handy.
>9) Much easier backport of patches to release branches: "svn
>merge -r123456", which also correctly remove/add/rename files as needed.
>10) Getting rid forever of the problem with DOS newlines in source files.
>
>I would also notice that most people don't RTFM. I spent many efforts in
>writing the Wiki page, and the benefits of SVN are apparent if you spend
>some time reading it and studying the thing a little. To make things better,
>something *has* to change. You can't expect SVN to be *identical* to CVS,
>but it's very very close.
>  
>
Agreed, many thanks both to you and Steven.

Only one request from me: before the switch takes place, can you make
sure the instructions on the wiki are sufficiently complete and
incorporate all the latest advices about performance and so on? I think
this is an high priority and would even suggest delaying the switch if
we don't have those docs ready.

Thanks
Paolo.

Re: A couple more subversion notes

[Daniel Berlin]

On Wed, 2005-10-19 at 17:06 +0200, Paolo Carlini wrote:
> Daniel Berlin wrote:
> 
> >5. Lastly, just to be clear, if you guys don't think the benefits
> >outweigh the costs, we don't have to move.
> >So far, the amount of dissent i've heard is pretty small, but please, if
> >you don't want to move (or you do), please speak up, instead of silently
> >suffering (or silently being in joy).
> >  
> >
> Thanks Danny for asking. I'm reading the various messages coming to the list 
> and, well, I'm *worried* the benefits will *not* outweigh the costs for many 
> of us.
> 
> Sorry for the harsh and naive question: *which* are the benefits for people 
> *not* managing many branches?
No, it's a perfectly fair question.

For people not managing any branches, your main advantage is changesets,
local operations for diff/add/delete/move/etc, renaming files, and
everything is atomic.
This means no more waiting for locks, even during commits.
The only time it will complain at you is if someone has touched the
exact path you are trying to commit since you last updated.

If you want to pull or apply patches, or reghunt, you can do it by
revision number, instead of tring to figure out what files made up a
patch.
You just ask it for "the diff that produced revision 12312 from revision
12311" and that includes *the entire diff*, not just the changes for a
single file.

Scripts are easier to produce, since anything you can do from the
command line, you can do with the bindings, very easily..

However, this is also true of *any* newer revision control system from
CVS.

They all share the "disadvantages" of subversion (global revision
numbers, carrying around more data, etc).  In fact, AFAIK, none of them
actually let you work entirely disconnected without carrying repo
history (IE they won't go fetch things remotely in any automatic way),
in a way that a no-pristine copy subversion should.

So i guess the first decision is "do we want to stay with cvs forever,
or move to something different that has some advantages and some
disadvantages for most people, and very large advantages for some
people."

This *really* is the main decision.  The rest is just timing.

I'm not trying to force anything on anyone.
If we truly want to stay with CVS forever, let's do that.

But you should know that it's a pain in the ass for people trying to
manage branches of any sort, do any sort of renames, and who don't want
to wait 30 minutes to commit things while people tag.  We just don't
complain about those things because we had to live with them for so
long, we are used to this.

Also, considering we keep telling people to put changes and features on
branches, it is somewhat disingenuous to make that hard.
This is part of the reason people send large patches at the beginning of
stage1 that nobody has ever seen.  Nobody wants to maintain a branch for
something small.

Now, personally, i'm confident the disk space issue (both mirroring the
remote repo, and working copy size) will go away in a newer version of
subversion, most likely 1.4 (unless disaster strikes, that's where the
patch i'm working on should end up).

svnserve is getting ssl and SASL support, which should be in 1.4, and we
would be able to use that in place of SVN+SSH, which should provide
stuff without the overhead of SSH.

However, there will always be issues, no matter when we move.
There is always something better down the pipe that will fix issues.

The longer you wait, the bigger your initial repos are going to be.
In february, the converted repo was 6 gig :)

cvs2svn is very good at what it does, but it has a very tough life
trying to convert file revisions into changesets, and make single
revision branches and tags out of mashed potatoes.

As for other VCS'en, Subversion has the advantage that i know how to fix
the issues we have, and will do so personally, if nobody else does.
This of course, will take time, but i can make that promise because i'm
a subversion committer, and i know how to get things into subversion
releases.


--Dan

Re: A couple more subversion notes

[Daniel Jacobowitz]

On Wed, Oct 19, 2005 at 05:26:42PM +0200, Andreas Schwab wrote:
> "Giovanni Bajo" <[EMAIL PROTECTED]> writes:
> 
> > I put ControlPath in the config file, and then run "ssh -fMN host" at
> > startup. When is it barfing for you?
> 
> According to the wiki ssh is supposed to ignore the controlpath when it
> doesn't exist, but instead it barfs.
> 
> > If I remove the socket file, it just does a normal connection.
> 
> It doesn't for me.
> 
> $ ssh gcc.gnu.org
> Couldn't connect to /var/tmp/schwab/ssh_%h: No such file or directory

Yes, the lack of expanded %h means that you're looking at an older
version of OpenSSH; I guess the missing ControlPath support was also a
bug fix.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Making a new cross-compile target: where to begin?

[[EMAIL PROTECTED]]

Hi,

I know that some people are working on a GCC port for Minix v3, but
I'd like to work on a cross-compiler for my own purposes.  I'd like
the host and build to be i686-pc-linux-gnu, and the target to be
i[3456]86-pc-minix3.

Can anyone give me some advice on where to begin and what info I need?
 The most obvious issue is that binutils needs to be aware of the
Minix 3 a.out object file format, unless I tweak things so that a
program that converts statically linked ELF object files into a.out
object files runs automatically after a build.  I'm not sure what the
best approach would be.

There are probably some good docs out there on making a new
cross-compile target, but I haven't found them.  Do they exist, and if
yes where are they?  What new files do I need to help GCC build for a
Minix 3 target, what do I put in them, where can I learn about writing
a specs file for Minix 3, etc.

Does anyone here have a knowledge of creating a new output object
format for binutils?  I would guess that I will be patching binutils
to accept new command line options, arranging for BFD to write a.out
files, and maybe other things.  Again, not sure where to begin.

I would like to use the GCC 4 series, and binutils 2.16.1+.  The goal
is to get a cross compiler to build for a Minix 3 system on i3[456]86
systems that runs on a GNU/Linux system, so I can use it to build all
sorts of other programs for a Minix 3 system that I can't compile on
Minix 3, like most of the GNU programs, as well as the latest Perl and
Python, etc, so I can end up with a GNU/Minix 3 system.  From there
when everything is built, tested and installed, I should be able to
use the GNU/Minix 3 system itself to be self-hosting.

Thanks for your help.

James Buchanan

Re: A couple more subversion notes

[Andreas Schwab]

"Giovanni Bajo" <[EMAIL PROTECTED]> writes:

> Ah, maybe it's a later fix? I'm using:
>
> $ ssh -V
> OpenSSH_4.2p1, OpenSSL 0.9.7f 22 Mar 2005

Maybe, I'm using 4.1p1.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Making a new cross-compile target: where to begin?

[Jonathan Bastien-Filiatrault]

[EMAIL PROTECTED] said:
> Hi,
>
> I know that some people are working on a GCC port for Minix v3, but
> I'd like to work on a cross-compiler for my own purposes.  I'd like
> the host and build to be i686-pc-linux-gnu, and the target to be
> i[3456]86-pc-minix3.
>
> Can anyone give me some advice on where to begin and what info I need?
>  The most obvious issue is that binutils needs to be aware of the
> Minix 3 a.out object file format, unless I tweak things so that a
> program that converts statically linked ELF object files into a.out
> object files runs automatically after a build.  I'm not sure what the
> best approach would be.
Well, Daniel Kegel's crosstool is the best place to learn on how to
_build_ a cross compiling toolchain.


> There are probably some good docs out there on making a new
> cross-compile target, but I haven't found them.  Do they exist, and if
> yes where are they?  What new files do I need to help GCC build for a
> Minix 3 target, what do I put in them, where can I learn about writing
> a specs file for Minix 3, etc.
Well, as far as I have seen, most of the internals are documented in the
code itself. The best way to learn how it works, in my opinion, is to get
a good code cross-reference tool. The files you mostly want to look at are
in gcc/config in a build tree.

[snip]
> Thanks for your help.
>
> James Buchanan
>

Good luck and have fun,
Jonathan Bastien-Filiatrault

Re: using multiple trees with subversion

[Mike Stump]

On Oct 19, 2005, at 2:56 AM, François-Xavier Coudert wrote:
Or am I the only person to find that disk is expensive (or working  
on his own hardware, maybe)?


A checkout costs US$0.50.  This is around 2.6x more expensive than a  
cvs checkout.  Check around locally, maybe you can find `throwaways'  
in the 4GB-15GB range.



throwaways - what a person that likes to upgrade every 3-5 years  
throws out, because its too slow/small to do anything with.

The move to subversion

[Loren James Rittle]

Daniel,

As a long-time user of CVS (before it was a binary ;-) that recently
read the "Turtle book" and as a long-time user of the open gcc source
tree (although less so recently), I am very happy with the proposed
move to svn.  Thank you and all the svn developers for all your hard
work to make it happen.  BTW, as Ian noted, this .ssh/config entry
allows access to the new test svn behind an SSL firewall:

Host gcc.gnu.org
Protocol 1
ForwardX11 no
ForwardAgent no
ProxyCommand ssl-tunnel.pl wwwgate0.mot.com 1080 sshproxy.sourceware.org 443

This allowed me to replace local hacks that I had used for years to
generate an ssh path and which I could not get to work with your old
test svn at svn.toolchain.org...

Regards,
Loren

Re: A couple more subversion notes

[Daniel Berlin]

On Wed, 2005-10-19 at 17:40 +0200, Paolo Carlini wrote:
> Giovanni Bajo wrote:
> 
> >I'll add others:
> >
> >I would also notice that most people don't RTFM. I spent many efforts in
> >writing the Wiki page, and the benefits of SVN are apparent if you spend
> >some time reading it and studying the thing a little. To make things better,
> >something *has* to change. You can't expect SVN to be *identical* to CVS,
> >but it's very very close.
> >  
> >
> Agreed, many thanks both to you and Steven.
> 
> Only one request from me: before the switch takes place, can you make
> sure the instructions on the wiki are sufficiently complete and
> incorporate all the latest advices about performance and so on? I think
> this is an high priority and would even suggest delaying the switch if
> we don't have those docs ready.


Well i guess i should aks the harsh question, which is, are these
advantages enough for you guys, or should we just not move?


Again, there are invariably some pains associated with any switch in
workflow :)

Re: A couple more subversion notes

[Paolo Carlini]

Daniel Berlin wrote:

>Well i guess i should aks the harsh question, which is, are these
>advantages enough for you guys, or should we just not move?
>  
>
FWIW my personal opinion, indeed are enough from me (in particular, some
time ago, I have been discussing the diff preparation thing with Matt
Austern and others, thanks to Giovanni for reminding me that!),
*provided* the knowledgeable people volunteer to summarize on the wiki
also the latest advices about svk, ssh, and what else...

Paolo.

Re: A couple more subversion notes

[Andrew Haley]

Daniel Berlin writes:
 > On Wed, 2005-10-19 at 17:40 +0200, Paolo Carlini wrote:
 > > Giovanni Bajo wrote:
 > > 
 > > >I'll add others:
 > > >
 > > >I would also notice that most people don't RTFM. I spent many efforts in
 > > >writing the Wiki page, and the benefits of SVN are apparent if you spend
 > > >some time reading it and studying the thing a little. To make things 
 > > >better,
 > > >something *has* to change. You can't expect SVN to be *identical* to CVS,
 > > >but it's very very close.
 > > >  
 > > >
 > > Agreed, many thanks both to you and Steven.
 > > 
 > > Only one request from me: before the switch takes place, can you make
 > > sure the instructions on the wiki are sufficiently complete and
 > > incorporate all the latest advices about performance and so on? I think
 > > this is an high priority and would even suggest delaying the switch if
 > > we don't have those docs ready.
 > 
 > Well i guess i should aks the harsh question, which is, are these
 > advantages enough for you guys, or should we just not move?
 > 
 > Again, there are invariably some pains associated with any switch in
 > workflow :)

I've been browsing gcc change sets, and I have to say it's very nice
feature!

I'm in favour of the change if we can get a decent ssh tunnelling
solution sorted out so that "svn diff" is decently fast.

Andrew.

Re: A couple more subversion notes

[Diego Novillo]

On Wednesday 19 October 2005 14:36, Daniel Berlin wrote:

> Well i guess i should aks the harsh question, which is, are these
> advantages enough for you guys, or should we just not move?
>
I vote 'move'.

Re: RFC: future gfortran development and subversion

[Tobias Schlüter]

[ I've added gcc@ to the CC list and reproduced the message in full, FX
already got the "buy a bigger harddisk" answer there, I think it makes sense
to show that other people care about this, too ]

Steve Kargl wrote:
> I fear the impending switch to subversion will have a negative impact on
> the future development of gfortran due the rather limited number of people
> who actually supply patches and the sudden increase in hardware 
> requirements.   For example, I find
> 
> troutmask:sgk[204] du -sh gcc40 gcc41 trunk 241Mgcc40   <-- CVS 4.0
> branch 275Mgcc41   <-- CVS mainline 694Mtrunk   <-- svn mainline
> 
> gfortran on 4.0 and mainline are sufficiently out of sync that the backport
> of changes is becoming difficult. Additionally, some of us, who have large
> changes or test large changes, have more than one copy of CVS mainline.
> 
> With the impending branch of 4.1, this will look like
> 
> 241Mgcc40   <-- CVS 4.0 branch 275Mgcc41   <-- CVS 4.1 branch 275M
> gcc42   <-- CVS mainline
> 
> which is tolerable (even with a few copies of mainline for large change
> sets).  But, svn would give
> 
> 694Msvn40   <-- svn 4.0 branch 694Msvn41   <-- svn 4.1 branch 694M
> trunk   <-- svn mainline
> 
> Now add one or two additional svn directories for large change sets and
> this becomes intolerable.  (Before anyone spews "disk space is cheap", I'll
> gladly accept any scsi U320 disks you wish to send to me).

If you have multiple directories containing the same branch it should
be possible to set up a very small svk repository which essentially doesn't
more than keep a common pristine copy for all the two or three checkouts you
want to keep (i.e. no or only very little history).  A little information on
using svk has made it into the wiki, but it's not yet very informative.

> Now, to my proposal for future gfortran development post 4.1 branching.
> When (if) svn becomes the source code revision tool, I propose that all
> future work be done solely on mainline.  No individual patches can be
> merged into 4.1.  The 4.0 branch will be dead.  Periodically, say bi-weekly
> or monthly, we do a merge from mainline into 4.1.  The aim is to keep 4.1
> and mainline sufficiently in sync and to minimize the requirements of
> additional hardware (except for the day or two required for the merge) and
> to maximize our time investment.

This should actually be feasible with svn merge, before on cvs this would have
been a tedious task.  I fear that this approach will fail to insufficient
volunteer time, though.

- Tobi

Re: RFC: future gfortran development and subversion

[Steve Kargl]

On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote:
> > 
> > 694Msvn40   <-- svn 4.0 branch 694Msvn41   <-- svn 4.1 branch 694M
> > trunk   <-- svn mainline
> > 
> > Now add one or two additional svn directories for large change sets and
> > this becomes intolerable.  (Before anyone spews "disk space is cheap", I'll
> > gladly accept any scsi U320 disks you wish to send to me).
> 
> If you have multiple directories containing the same branch it should
> be possible to set up a very small svk repository which essentially doesn't
> more than keep a common pristine copy for all the two or three checkouts you
> want to keep (i.e. no or only very little history).  A little information on
> using svk has made it into the wiki, but it's not yet very informative.

OK, I'll go read about svk.  I scanned the svn docs for an
--exclude-dir= option or .svnrc file where excluding directories
could be done.  So far, I've come up empty.  I don't build nor
work in the ada, java, and C++ directories.  It would be great
if we could tell svn to ignore certain directories to recover
wasted space.

> > Now, to my proposal for future gfortran development post 4.1 branching.
> > When (if) svn becomes the source code revision tool, I propose that all
> > future work be done solely on mainline.  No individual patches can be
> > merged into 4.1.  The 4.0 branch will be dead.  Periodically, say bi-weekly
> > or monthly, we do a merge from mainline into 4.1.  The aim is to keep 4.1
> > and mainline sufficiently in sync and to minimize the requirements of
> > additional hardware (except for the day or two required for the merge) and
> > to maximize our time investment.
> 
> This should actually be feasible with svn merge, before on cvs this would have
> been a tedious task.  I fear that this approach will fail to insufficient
> volunteer time, though.

You might be right.  I have a large back log of patches in my inbox
that I need to review for mainline.  It's getting to the point that
I simply lack the time and resources to track multiple branches, so
in the future I may only be able to provide review and approval 
of gfortran patches for mainline.

-- 
Steve

Re: A couple more subversion notes

[Mark Mitchell]

Diego Novillo wrote:
> On Wednesday 19 October 2005 14:36, Daniel Berlin wrote:
> 
> 
>>Well i guess i should aks the harsh question, which is, are these
>>advantages enough for you guys, or should we just not move?
>>
> I vote 'move'.

I've never used subversion -- this is the first time I know of that I've
typed "svn".  I hate upgrades.  Their cost is always bigger than
expected, even if you take that fact into account.  (A variant of
Hofstdater's law...)

And, yet, I think we should move.

We've discussed this extensively at CodeSourcery, and I think everyone
is uniformly in favor.  The superior branch facilities are a key
benefit.  You got us through the Bugzilla transition, and that's working
well.  Make it happen.

-- 
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: RFC: future gfortran development and subversion

[Tobias Schlüter]

Steve Kargl wrote:
> On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote:
> 
>>>694Msvn40   <-- svn 4.0 branch 694Msvn41   <-- svn 4.1 branch 694M
>>>trunk   <-- svn mainline
>>>
>>>Now add one or two additional svn directories for large change sets and
>>>this becomes intolerable.  (Before anyone spews "disk space is cheap", I'll
>>>gladly accept any scsi U320 disks you wish to send to me).
>>
>>If you have multiple directories containing the same branch it should
>>be possible to set up a very small svk repository which essentially doesn't
>>more than keep a common pristine copy for all the two or three checkouts you
>>want to keep (i.e. no or only very little history).  A little information on
>>using svk has made it into the wiki, but it's not yet very informative.

Oh yes, this is an interesting question.  In CVS I could just delete
directories that I didn't care about in my local checkout.  Is something like
this possible in svn?  Simply deleting libada results in it being added again
during the next 'svn up'.

- Tobi

Re: A couple more subversion notes

[Joe Buck]

Re: moving to subversion

On Wed, Oct 19, 2005 at 12:19:52PM -0700, Mark Mitchell wrote:
> We've discussed this extensively at CodeSourcery, and I think everyone
> is uniformly in favor.  The superior branch facilities are a key
> benefit.  You got us through the Bugzilla transition, and that's working
> well.  Make it happen.

It seems that there is consensus, but let's be sure.  Certainly as the guy
who has to produce the releases, Mark's voice should weigh most heavily.

Are there any maintainers (folks in MAINTAINERS) who have objections or
concerns?

Going once, as they say ...

Re: RFC: future gfortran development and subversion

[Daniel Berlin]

On Wed, 2005-10-19 at 12:16 -0700, Steve Kargl wrote:
> On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote:

> OK, I'll go read about svk.  I scanned the svn docs for an
> --exclude-dir= option or .svnrc file where excluding directories
> could be done.  So far, I've come up empty.  I don't build nor
> work in the ada, java, and C++ directories.  It would be great
> if we could tell svn to ignore certain directories to recover
> wasted space.

You could simply do non-recursive checkouts (svn co -N) of the dirs you
want.
SVN doesn't care how you piece together the working copy.


--Dan

Re: A couple more subversion notes

[Richard Kenner]

 Are there any maintainers (folks in MAINTAINERS) who have objections or
 concerns?

Well, I haven't tried it myself yet, so what I'm going by is hearsay but
I do share the concern that it's looking like this is a change that may
make the common things harder and slower in order to make the less common
operations faster and/or easier.  If so, that may not be the right tradeoff.

Re: RFC: future gfortran development and subversion

[Richard Guenther]

On 10/19/05, Tobias Schlüter <[EMAIL PROTECTED]> wrote:
>
> [ I've added gcc@ to the CC list and reproduced the message in full, FX
> already got the "buy a bigger harddisk" answer there, I think it makes sense
> to show that other people care about this, too ]
>
> Steve Kargl wrote:
> > Now, to my proposal for future gfortran development post 4.1 branching.
> > When (if) svn becomes the source code revision tool, I propose that all
> > future work be done solely on mainline.  No individual patches can be
> > merged into 4.1.  The 4.0 branch will be dead.  Periodically, say bi-weekly
> > or monthly, we do a merge from mainline into 4.1.  The aim is to keep 4.1
> > and mainline sufficiently in sync and to minimize the requirements of
> > additional hardware (except for the day or two required for the merge) and
> > to maximize our time investment.

Dude, I hope fortran will, after branching of 4.1, follow the usual rules
of regression fixes only.  This means development will be on mainline
only anyways, as for any other language.  And occasional backporting of
bugfixes should be not a too great burden.

I definitely hope we're not ending up applying large fortran changes to
a release series again.  (Ok, 4.0 _was_ special ...)

Richard.

Re: RFC: future gfortran development and subversion

[Steve Kargl]

On Wed, Oct 19, 2005 at 10:06:44PM +0200, Richard Guenther wrote:
> On 10/19/05, Tobias Schl?ter <[EMAIL PROTECTED]> wrote:
> > Steve Kargl wrote:
> > > Now, to my proposal for future gfortran development post 4.1 branching.
> > > When (if) svn becomes the source code revision tool, I propose that all
> > > future work be done solely on mainline.  No individual patches can be
> > > merged into 4.1.  The 4.0 branch will be dead.  Periodically, say 
> > > bi-weekly
> > > or monthly, we do a merge from mainline into 4.1.  The aim is to keep 4.1
> > > and mainline sufficiently in sync and to minimize the requirements of
> > > additional hardware (except for the day or two required for the merge) and
> > > to maximize our time investment.
> 
> Dude, I hope fortran will, after branching of 4.1, follow the usual rules
> of regression fixes only.  This means development will be on mainline
> only anyways, as for any other language.

Please define regression.

> And occasional backporting of bugfixes should be not a too great burden.

The sky is blue in my world.

> I definitely hope we're not ending up applying large fortran changes to
> a release series again.  (Ok, 4.0 _was_ special ...)

Whatever.

-- 
Steve

Re: A couple more subversion notes

[Giovanni Bajo]

Richard Kenner <[EMAIL PROTECTED]> wrote:

>  Are there any maintainers (folks in MAINTAINERS) who have objections
or
>  concerns?
>
> Well, I haven't tried it myself yet, so what I'm going by is hearsay but
> I do share the concern that it's looking like this is a change that may
> make the common things harder and slower in order to make the less common
> operations faster and/or easier.  If so, that may not be the right
tradeoff.

I understand the concern, but let me assure you: I strongly believe that
this is not true. The only issue here is that people are trying to configure
SVN using our Wiki page as the only reference (and not everybody even did
that). Daniel and I wrote that page, but it is not meant to contain the
answers for all the questions, nor the solve all configuration problems. We
*never* had such a page for CVS as well: if it didn't work, people simply
googled until they found the solution.

Yet, to help the transition, we *are* preparing a documentation and we *are*
helping people moving. There will be issues in the transition. But the
result is that the common things will be faster and easier, and the less
common things will be so incredibly faster and easier that might become more
common about hackers -- which I see as a good thing.
-- 
Giovanni Bajo

Re: RFC: future gfortran development and subversion

[Richard Guenther]

On 10/19/05, Steve Kargl <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 19, 2005 at 10:06:44PM +0200, Richard Guenther wrote:
> > On 10/19/05, Tobias Schl?ter <[EMAIL PROTECTED]> wrote:
> > > Steve Kargl wrote:
> > > > Now, to my proposal for future gfortran development post 4.1 branching.
> > > > When (if) svn becomes the source code revision tool, I propose that all
> > > > future work be done solely on mainline.  No individual patches can be
> > > > merged into 4.1.  The 4.0 branch will be dead.  Periodically, say 
> > > > bi-weekly
> > > > or monthly, we do a merge from mainline into 4.1.  The aim is to keep 
> > > > 4.1
> > > > and mainline sufficiently in sync and to minimize the requirements of
> > > > additional hardware (except for the day or two required for the merge) 
> > > > and
> > > > to maximize our time investment.
> >
> > Dude, I hope fortran will, after branching of 4.1, follow the usual rules
> > of regression fixes only.  This means development will be on mainline
> > only anyways, as for any other language.
>
> Please define regression.

A regression is a bug that was not in release N - M and was discovered
in release N.  You are then free to fix N - M + 1 to N.  Like you have
a
testcase that crashes gfortran on 4.1.0, but did not on 4.0.2.

Richard.

Re: RFC: future gfortran development and subversion

[FX Coudert]

A regression is a bug that was not in release N - M and was discovered
in release N.  You are then free to fix N - M + 1 to N.  Like you have
a testcase that crashes gfortran on 4.1.0, but did not on 4.0.2.


But then, you'll explain people that they won't have a decent fortran 
compiler in distros before .


The fortran patches are always fortran-contained, and I think if the 
community thinks it worth to have a different development model (until 
some point in the future, defined in advance) why shouldn't it be so?


FX

Re: Making a new cross-compile target: where to begin?

[[EMAIL PROTECTED]]

> Well, as far as I have seen, most of the internals are documented in the
> code itself. The best way to learn how it works, in my opinion, is to get
> a good code cross-reference tool. The files you mostly want to look at are
> in gcc/config in a build tree.
>
> Good luck and have fun,
> Jonathan Bastien-Filiatrault

Maybe a good place to get clues is to look at how GCC and binutils are
built for DOS, e.g. DJGPP.  (I've asked DJ for some help).  Starting
with the config stuff for DJGPP will probably help me along.  DOS is a
similar job to Minix in that it has less facilities than systems like
full-blown Unixen.

I will try to have fun, after all the blood and sweat parts anyway. :)
 I'm really eager to learn how all this GCC magic works.

James

Re: Making a new cross-compile target: where to begin?

[DJ Delorie]

> Maybe a good place to get clues is to look at how GCC and binutils are
> built for DOS, e.g. DJGPP.  (I've asked DJ for some help).

Except that DJGPP uses COFF, not a.out.  DJGPP v1 used a.out, but most
of that support has been removed by now.

Re: RFC: future gfortran development and subversion

[Paul Thomas]

FX,



The fortran patches are always fortran-contained, and I think if the 
community thinks it worth to have a different development model (until 
some point in the future, defined in advance) why shouldn't it be so?


This might well be the value of keeping the binaries going.  From what I 
can see, most people using gfortran in anger are updating from your 
site, rather than using the distros.


I think that keeping two lines going is a pain but just about OK; better 
would be to undertake the periodic synchronizations from Head to 4.1, 
even if we are a bit resource limited.  As it is, this latter makes for 
some of the divergence because not all patches make their way to the 
distribution version.


By the way, I just posted on the Wiki a comparison of DF6.0 and gfortran 
using the Polyhedron benchmarks.  It's not too bad at all but there are 
a couple of sore thumbs.  I have just done the ifc to gfortran 
comparison on FC3, which basically looks the same (one bloody thumb is 
repaired because the comparison is not between a native user of system 
resources and another that does so via Cygwin.).  I will try to collate 
and post the results in a day or so.


Paul

Re: Making a new cross-compile target: where to begin?

[[EMAIL PROTECTED]]

On 10/20/05, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> > Maybe a good place to get clues is to look at how GCC and binutils are
> > built for DOS, e.g. DJGPP.  (I've asked DJ for some help).
>
> Except that DJGPP uses COFF, not a.out.  DJGPP v1 used a.out, but most
> of that support has been removed by now.

Perhaps I'll be able to get away with --target=i386-aout and simply
modifying glibc, newlib or uclibc to use Minix's system calls, and
it'll all work with minor tweaks like the specs files GCC uses.  I'll
try it.  I'll post my experiences to the GCC developers' list in case
others in future find it useful as a starting point to GNU-ify a new
system.

Re: A couple more subversion notes

[Bernd Schmidt]

Joe Buck wrote:


Are there any maintainers (folks in MAINTAINERS) who have objections or
concerns?


I haven't played with svn much, but from what I hear about the 
advantages I'm all for it.  cvs is so 20th century.



Bernd

Re: RFC: future gfortran development and subversion

[Andrew Pinski]

On Oct 19, 2005, at 4:36 PM, FX Coudert wrote:


A regression is a bug that was not in release N - M and was discovered
in release N.  You are then free to fix N - M + 1 to N.  Like you have
a testcase that crashes gfortran on 4.1.0, but did not on 4.0.2.


But then, you'll explain people that they won't have a decent fortran 
compiler in distros before 2007>.


Hey that was how it was done back in the EGCS days anyways.  This is 
same reason
why some distro used EGCS instead of GCC.  But we (GCC) should not 
worry about

this any more, if a distro wants to backport a patch, they are more than
welcome to.

GCC and gfortran (and gcj) should all play by the normal rules that we 
made

to GCC so that we don't spend too much time backporting (and looking
backwards) instead of fixing bugs.

-- Pinski

Re: RFC: future gfortran development and subversion

[Thomas Koenig]

On Wed, Oct 19, 2005 at 10:06:44PM +0200, Richard Guenther wrote:

> Dude, I hope fortran will, after branching of 4.1, follow the usual rules
> of regression fixes only.

Currently, gfortran is in a half-usable state.  It is not yet
ready as a replacement for g77 (see PR 19292) and there are quite
a lot of things it gets wrong with Fortran 95.

Not being able to backport important bug fixes to 4.1 would
leave out Fortran users out in the cold until 4.2 is shipped with
distributions.

Re: RFC: future gfortran development and subversion

[Steve Kargl]

On Wed, Oct 19, 2005 at 03:36:08PM -0400, Daniel Berlin wrote:
> On Wed, 2005-10-19 at 12:16 -0700, Steve Kargl wrote:
> > On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote:
> 
> > OK, I'll go read about svk.  I scanned the svn docs for an
> > --exclude-dir= option or .svnrc file where excluding directories
> > could be done.  So far, I've come up empty.  I don't build nor
> > work in the ada, java, and C++ directories.  It would be great
> > if we could tell svn to ignore certain directories to recover
> > wasted space.
> 
> You could simply do non-recursive checkouts (svn co -N) of the dirs you
> want.
> SVN doesn't care how you piece together the working copy.
> 

I don't mean to be dense, but I'll need a working example.

svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk -N

This checks out the files in the toplevel directory.

svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/libada trunk/libada -N

This checks out the files in trunk/libada and places them in trunk/libada.

cd trunk
rm libada/ChangeLog
svn update

This does not retrieve/restore the deleted file.  This means that
to construct the gcc directory hierarchy without libada, one needs
to know all the subdirectories of trunk/ and grab those individually.
Then one can't do a global update from trunk/.  You have to go
into each subdirectory to do the update.

Isn't there a mechanism similar to .cvsignore where one can
put *libada* to ignore libada?  svn has a svn:ignore, but I
have been unsuccessful in my attempts at using it.

-- 
Steve

Is gcc optimized for thread level parallelism?

[x z]

Is gcc optimized for thread level parallelism, in view of the recent 
development of SMT and multicore architectures?  Does gcc look for thread 
level parallelism given a single threaded program (that is, when the 
programmer does not parallelize the program using pthread etc.)?
And does gcc support any NUMA (non-uniform memory access) machines?  That 
is, does gcc
a) automatically parallelize the program for as many processors in the 
machine as possible?
b) take advantage of the non-uniform memory access (i.e. co-locate a thread 
and the data it needs on a particular processor)?

Re: Is gcc optimized for thread level parallelism?

[Joe Buck]

On Wed, Oct 19, 2005 at 10:35:29PM +, x z wrote:
> Is gcc optimized for thread level parallelism, in view of the recent 
> development of SMT and multicore architectures?  

No.

> And does gcc support any NUMA (non-uniform memory access) machines?  That 
> is, does gcc
> a) automatically parallelize the program for as many processors in the 
> machine as possible?

No.

> b) take advantage of the non-uniform memory access (i.e. co-locate a thread 
> and the data it needs on a particular processor)?

No.

Re: RFC: future gfortran development and subversion

[Joe Buck]

On Wed, Oct 19, 2005 at 05:06:40PM -0400, Andrew Pinski wrote:
> GCC and gfortran (and gcj) should all play by the normal rules that we
> made to GCC so that we don't spend too much time backporting (and
> looking backwards) instead of fixing bugs.

gfortran is the replacement for g77, and it still doesn't handle valid
code that g77 handles in some cases.  So to paraphrase Bill Clinton, it
all depends on what we mean be the word "regression".

One interpretation is that it's only a regression if some previous release
of gfortran (aka g95) worked and the current one does not.  But some could
make an argument that if g77 handled a case and GNU Fortran now does not,
we have a regression.  This would not be a hole to allow introduction of
missing Fortran 95 or newer features into minor releases, unless g77
already supported the features.  Still, such a criterion might lead to too
much instability.

So maybe there can be a compromise between those two positions that would
allow for changes to gfortran to add missing g77 functionality, even for
x.y.n+1 releases, as long as only the Fortran front end is affected and
the changes are considered highly safe by the maintainers, and nothing
else breaks.

Andrew, you mention gcj, but that's in a different category; there is no
older gcj that was in some ways better and that we still haven't caught up
with.  I think it's reasonable for the gfortran folks to want to be able
to kill off the need for g77 as soon as they can.

Re: RFC: future gfortran development and subversion

[Kean Johnston]

I fear the impending switch to subversion will have a negative impact on
the future development of gfortran due the rather limited number of people
who actually supply patches and the sudden increase in hardware 
requirements.   For example, I find


troutmask:sgk[204] du -sh gcc40 gcc41 trunk 241Mgcc40   <-- CVS 4.0
branch 275Mgcc41   <-- CVS mainline 694Mtrunk   <-- svn mainline



This is one of the less fortunate aspects of svn. A lot of that
increased space is due to the fact that every single file in the
repository is duplicated. Once in its normal location, and again
in the .svn directory. This "feature" has been much-discussed.
Search the svn archives for "textbase penalty". I am glad I am
not the only one who feels that duplicating every single file is
a problem. If you bring it up on teh svn list though, be prepared
to be regailed with the merrits of being able to sit on an aeroplane
and do an 'svn diff' with no access to the repository (because
we all know that most serious developers spend most of their time
in planes, unattached to their repo network).

I recently tried to re-open the discussion on the svn list but
got nowhere. I would *dearly* love to see an option to svn that
uses a simple checksum or something to figure out if a file has
changed, or an 'svn edit' that copies the file to the textbase
on an as-needed basis. I fear it will never happen though.

I too have to purchase a new hdd to do gcc work on, because my
8G drive just isn't enough any more. On the bright side, I will
be replacing an old SCSI-II hdd with a 140G U320 drive, so svn
can check the files out in triplicate for all I care :)

Kean

Re: A couple more subversion notes

[Devang Patel]

I've never used subversion before but I have subversion book on my desk.
It's time to open it very first time!

You say that it is easier to manage multiple branches using
subversion. This is enough to get my vote in favor of this transition.

My question is - What's the plan regarding cvs respoistory once svn
repository goes live on 22nd Oct ? Will it immediately become
read-only for everyone?  Completely disapper? Use at your own risk? I
don't know?

Thanks for leading this transition,
-
Devang

Re: RFC: future gfortran development and subversion

[Daniel Berlin]

On Wed, 2005-10-19 at 16:55 -0700, Kean Johnston wrote:
> >>I fear the impending switch to subversion will have a negative impact on
> >>the future development of gfortran due the rather limited number of people
> >>who actually supply patches and the sudden increase in hardware 
> >>requirements.   For example, I find
> >>
> >>troutmask:sgk[204] du -sh gcc40 gcc41 trunk 241Mgcc40   <-- CVS 4.0
> >>branch 275Mgcc41   <-- CVS mainline 694Mtrunk   <-- svn mainline
> >>
> 

> 
> I recently tried to re-open the discussion on the svn list but
> got nowhere.

I saw no postings that contained anything like a design for doing this,
etc, to the dev list from you.

Only posts to the user list saying that you'd like no text base.
That's nice.  What did you expect?  Some users will agree with you, and
some won't.  If you went to Slashdot, and says "i'd like gcc to optimize
better", you'd probably get a similar cross section of answers.

Of course, you seem represent this thread you started as having actually
involved any subversion developers, which it didn't, AFAIK, and as
something that was potentially productive, which it stood no chance of
being, given how you wrote it.

Nobody on the dev list actually disagrees with the idea of no-text-base
or compressed text base support in subversion, AFAIK.
However, like GCC, we are all volunteers.
It will happen when someone has time and effort to make it happen.

>  I would *dearly* love to see an option to svn that
> uses a simple checksum or something to figure out if a file has
> changed, or an 'svn edit' that copies the file to the textbase
> on an as-needed basis.
>  I fear it will never happen though.

Can you please stop fear-mongering?
The first is a known, planned feature for SVN, that actually had someone
from the Summer of Code working on it, which happened to not work out.
Sometimes these things happen.

To be perfectly honest, none of the people paid to work on subversion
have tackled it yet because *most users don't care about the penalty*.

It turns out we have users that do.
Thus, i will probably take some of my copious amounts of free time, and
work on it, if nobody else does.

--Dan

Re: RFC: future gfortran development and subversion

[Kean Johnston]

I saw no postings that contained anything like a design for doing this,
etc, to the dev list from you.

http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=106243


Of course, you seem represent this thread you started as having actually
involved any subversion developers, which it didn't, AFAIK, and as
something that was potentially productive, which it stood no chance of
being, given how you wrote it.

I dont know what you are refering to Dan. If there was something
wrong with the message quoted above please educate me (off this
list), becuase if there was something wrong with what I wrote
I just don't see it. Please note the last paragraph. I am
*volunteering* to make it happen. I asked for advice or pointers.
What replies did I get? "use svn export".


Can you please stop fear-mongering?

Say what??? Expressing an opinion that something is unlikely to
happen, based on lengthy discussions that indicate they wont,
is fear mongering? Come onnn.

You are being hyper critical, and its not necessary. This thread
has contained numerous reponses with concerns about the move
to svn, or problems users were having with the prototype etc.
I don't see you getting bent at anyone's post other than mine.
I'm not being paranoid here either. When you first announced on
the list the move to svn, I asked simply:

http://gcc.gnu.org/ml/gcc/2005-10/msg00054.html

"What is the actual problem you are trying to solve". The mail was
polite, respectful, non-inflamatory. I was told to shut the f*** up
and read the list archives because I was entering the discussion
late. But let someone *else* ask pretty much the same thing:

http://gcc.gnu.org/ml/gcc/2005-10/msg00545.html

And he gets polite, informative responses.

If my FQDN offends you that you (and others) are being so critical
and in many cases downright rude, please remember: I am an individual,
not a corporation. My personal views are wildly divergant from my
employers.

This list is starting to feel downright hostile. Its unprofessional
and uncalled for. But maybe thats just acceptable behaviour if
you're bashing the SCO guy. I may be just an email address you respond
to but I assure you I am a real, live human being, with real feelings
that are capable of (and recently, rather frequently ARE) being
hurt. But that's my problem, not yours.

In case it is not clear to you, and other GCC folks, let me assure
you that it is no accident that the only two projects I wish to spend
my time on are svn and gcc. I have a tremendous amount of respect and
admiration for the developers and designers of both tools. I am
constantly amazed and impressed at the quality and sometimes just
sheer brilliance present in both. And this is not idle flattery, it
is very sincerely meant. So please, in future, try not to look on my
mails as negative, for I *never* intend them to be so.

Sincerely, Kean.

Re: RFC: future gfortran development and subversion

[Daniel Berlin]

On Wed, 2005-10-19 at 19:43 -0700, Kean Johnston wrote:
> > I saw no postings that contained anything like a design for doing this,
> > etc, to the dev list from you.
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=106243
> 

Oh that one, i'm sorry, i confused your thread with another recent one.
My sincere apologies.

> > Of course, you seem represent this thread you started as having actually
> > involved any subversion developers, which it didn't, AFAIK, and as
> > something that was potentially productive, which it stood no chance of
> > being, given how you wrote it.
> I dont know what you are refering to Dan. If there was something
> wrong with the message quoted above please educate me (off this
> list), becuase if there was something wrong with what I wrote
> I just don't see it. 

You asked how to get a raw dump because you didn't want a .svn
directory, and said "No-one is ever going to be editing there."

That's what svn export does, exactly.  Produce you a raw dump
disconnected from subversion, without .svn directories, for when you
aren't going to be editing.

You didn't ask how work was going on making a no-text-base copy of
subversion, so nobody really told you?

> Please note the last paragraph. I am
> *volunteering* to make it happen. I asked for advice or pointers.
> What replies did I get? "use svn export".
> 
> > Can you please stop fear-mongering?
> Say what??? Expressing an opinion that something is unlikely to
> happen, based on lengthy discussions that indicate they wont,

Where do you see lengthy discussion saying it won't?  
That's the part i consider fear mongering.

Last I spoke to Karl Fogel, and Ben Collins-Sussman (two key subversion
developers), they were in no way opposed to such a feature, and in fact,
happy to see it.

Karl, Ben, have you ever seen a lengthy discussion indicating that
compressed and no-text base working copies are unlikely to happen?

--Dan

Re: A couple more subversion notes

[Gabriel Dos Reis]

Arnaud Charlet <[EMAIL PROTECTED]> writes:

| > Most of this is ssh overhead, because your diff is so small.
| 
| I disagree, the diff isn't small, it is of a typical/reasonable size I
| would say.
| 
| > The ssh multiplexing stuff just written up on the wiki should help.
| 
| Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
| so I cannot test that right now.

I have been following the discussion as someone who hasn't made the
move yet (and I should probably do so very soon because of releases,
but currently I've been travelling a lot and do not have reliable
connection all the way) and trying to learn.
My current impression is that each answer to issues people reported
(as to be expected in a move) is along the line of yet more
complicated settings.  That gets me a bit worried about the inflation
of "new technology" requirements.
I just got a new laptop that I formatted for "typical" development
with dual boot.  I'm worried about the 8 gigs stuff.  

Please refrain from "here are $X, buy yourself a new harddrive".

-- Gaby

Re: A couple more subversion notes

[Gabriel Dos Reis]

Daniel Berlin <[EMAIL PROTECTED]> writes:

| On Wed, 2005-10-19 at 17:40 +0200, Paolo Carlini wrote:
| > Giovanni Bajo wrote:
| > 
| > >I'll add others:
| > >
| > >I would also notice that most people don't RTFM. I spent many efforts in
| > >writing the Wiki page, and the benefits of SVN are apparent if you spend
| > >some time reading it and studying the thing a little. To make things 
better,
| > >something *has* to change. You can't expect SVN to be *identical* to CVS,
| > >but it's very very close.
| > >  
| > >
| > Agreed, many thanks both to you and Steven.
| > 
| > Only one request from me: before the switch takes place, can you make
| > sure the instructions on the wiki are sufficiently complete and
| > incorporate all the latest advices about performance and so on? I think
| > this is an high priority and would even suggest delaying the switch if
| > we don't have those docs ready.
| 
| 
| Well i guess i should aks the harsh question, which is, are these
| advantages enough for you guys, or should we just not move?

Frankly, I don't know.

I would like to try first before making a definitive answer.
However, reading this thread, I find the inflation on supporting tools
and trickery requirements a bit  daunting and too high an entry barrier.
If I have to install the lastest version of (system) tool X, Y and Z
-- which sometimes I can't on some of the machines I use for
development -- then I would say the answer is "no".  But, as I
mentioned before, I have to try (probably not before next week).

I'm grateful to those who put effort in documenting the process, but
some of the replies I found here let me with an initial feeling of
deep skepticism. 

| Again, there are invariably some pains associated with any switch in
| workflow :)

Indeed.

-- Gaby

Re: A couple more subversion notes

[Gabriel Dos Reis]

Joe Buck <[EMAIL PROTECTED]> writes:

| Re: moving to subversion
| 
| On Wed, Oct 19, 2005 at 12:19:52PM -0700, Mark Mitchell wrote:
| > We've discussed this extensively at CodeSourcery, and I think everyone
| > is uniformly in favor.  The superior branch facilities are a key
| > benefit.  You got us through the Bugzilla transition, and that's working
| > well.  Make it happen.
| 
| It seems that there is consensus, but let's be sure.  Certainly as the guy
| who has to produce the releases, Mark's voice should weigh most heavily.
| 
| Are there any maintainers (folks in MAINTAINERS) who have objections or
| concerns?

I've been travelling for the last couple or so weeks and did not have
the chance to test the svn repo.  I'm following the discussion to get
an idea of the transition issues and I must say I do have concerns.
If to make this work, we have to require the latest system tools X, Y
and Z, then we're placing too high a barrier.  Not everybody does its
development on its own laptop it can reformat or fiddle with.  I'm
looking forward to solutions that lower the entry barrier,
specifically with repect too OpenSSH, diff and svk.

-- Gaby